Apparatus for disseminating a series of episodes represented by media files as the episodes become available

ABSTRACT

An audio program and message distribution system in which a host system organizes and transmits program segments to client subscriber locations. The host organizes the program segments by subject matter and creates scheduled programming in accordance with preferences associated with each subscriber. Program segments are associated with descriptive subject matter segments, and the subject matter segments may be used to generate both text and audio cataloging presentations to enable the user to more easily identify and select desirable programming. A playback unit at the subscriber location reproduces the program segments received from the host and includes mechanisms for interactively navigating among the program segments. A usage log is compiled to record the subscriber&#39;s use of the provided program materials, to return data to the host for billing, to adaptively modify the subscriber&#39;s preferences based on actual usage, and to send subscriber-generated comments and requests to the host for processing. Voice input and control mechanisms included in the player allow the user to perform hands-free navigation of the program materials and to dictate comments and messages which are returned to the host for retransmission to other subscribers. The program segments sent to each subscriber may include advertising materials which the user can selectively play to obtain credits against the subscriber fee. Parallel audio and text transcript files for at least selected programming enable subject matter searching and synchronization of the audio and text files. Speech synthesis may be used to convert transcript files into audio format. Image files may also be transmitted from the server for synchronized playback with the audio programming.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a division of U.S. patent application Ser. No.12/380,908 filed on Mar. 4, 2009 and published as U.S. ApplicationPublication No. 2009/0198357. Application Ser. No. 12/380,908 is adivision of U.S. patent application Ser. No. 09/782,546 filed on Feb.13, 2001, published as U.S. Application Publication No. 2008/0155616,now U.S. Pat. No. 7,509,178. Application Ser. No. 09/782,546 is adivision of U.S. patent application Ser. No. 08/724,813 filed on Oct. 2,1996, now U.S. Pat. No. 6,199,076. This application claims the benefitof the filing date of all of the above identified applications. Thedisclosures of U.S. patent application Ser. Nos. 08/724,813 and09/782,546 and 12/380,908, and of U.S. Pat. Nos. 6,199,076 and 7,509,178are incorporated herein by reference.

FIELD OF THE INVENTION

This invention relates to electronic information distribution systemsand more particularly to a system for dynamically and interactivelyselecting and playing particular programs from a program library.

BACKGROUND OF THE INVENTION

The three dominant commercial systems for providing audio programming toa listeners are broadcast radio systems, cassette tape playback systemsand compact disk playback systems.

Broadcast radio uses both the AM and FM frequency bands making a largenumber of simultaneously broadcast programs available on an essentiallyrandom access basis. Unfortunately, since most broadcast stationsattempting to appeal to the same general listening audience, much of theprogramming is duplicative and special interest programs are broadcaston a limited basis. In addition, because there is no convenient way forlisteners to be aware of the wide variety of materials scheduled forbroadcast, most people listen to only a limited number of stations whichdependably broadcast the programming considered to be most acceptable.Even when desired programming is found, it must typically be listened towhen it is broadcast; that is, at times chosen by the broadcaster andnot the listener.

Tape and compact disk audio players offer the listener the opportunityto purchase specific music selections or albums performed by favoriteartists and to replay selections from these purchased recording wheneverdesired. Pushbutton track selection, as well as improved fidelity, hasmade the CD player the preferred choice of many, despite the cost andinconvenience of purchasing a library of desired disks. Unfortunately,specialized information programming, unlike music, is largelyunavailable on tape or disk, and that media is not capable of adequatelyconveying rapidly evolving information such as local and world news,weather reports, and rapidly changing trade and business information.Although broadcast radio provides adequate, up to the minute coverage ofgeneral news topics, specialized information continues to be largelyunavailable on any of these three audio delivery systems, notwithstanding the fact that radio, tape and CD players continue to bewidely used, particularly in automobiles, for general news and musicprogramming.

More recently, “Internet radio” sources has been introduced which makefiles of audio program material available for downloading on the WorldWide Web using conventional web browsers to locate and request specificfiles which are then played in real time by special programs, includingthe popular “Real Audio” program offered by Progressive Networks.Although Internet radio systems make it possible to deliver a richlydiverse selection of audio programs to interested listeners on request,including specialized information not offered by conventional broadcastmedia, the use of a visual web browser to search for and then playindividual program selections one at a time makes conventional Internetradio players impractical for routine desktop use, and wholly unsuitablefor use by an automobile drive.

It is accordingly an object of the present invention to provide easyaccess to rich selection of audio programming and to allow the listenerto dynamically and interactively locate and select desired programmingfrom the available collection in an easy and intuitive way without theneed for a visual display screen and using only simple selectioncontrols.

SUMMARY OF THE INVENTION

The present invention takes the form of an audio program player whichautomatically plays a predetermined schedule of audio program segmentsand which further includes simple controls that allow the listener toperform one or more of the following functions:

-   -   to skip the remainder of any segment being played in order to        listen to the next program segment;    -   to skip backward to the beginning of the current segment, and        then backward again to the beginning of the prior segment on the        schedule, thereby replaying any desired segment or search for a        previously played segment in the sequence;    -   to listen if desired to an audio speech announcement describing        each segment before it is played, and to skip the forward or        backward to the next or prior announcement, thereby immediately        obtaining the information needed to determine whether a given        segment is or is not of interest;    -   to listen if desired to an audio speech announcement describing        a subject matter categories within which several program        segments are grouped, and to skip from category announcement to        category announcement in either the forward or reverse        direction, skipping all program segments in categories of        insufficient interest;    -   to listen to only predetermined highlight passages in any        program segment, thereby more rapidly reviewing the highlights        only of a program segment with the ability to commence normal        playing at any point where the highlight passage reveals        information which the listener desires to hear in more detail;    -   to execute a hyperlink jump to a different, cross-referenced        position in the program sequence, or to a program segment not        specified in the program sequence, and to provide audible cues        to the listener to identify passages which identify the presence        of a cross-referencing hyperlink.

According to a further feature of the invention, the audio programplayer plays program segments in an order determined by a sessionschedule which identifies an ordered sequence of program segments. Thesession schedule is preferably created in the first instance by a serversubsystem which develops and periodically transmits to the sessionschedule to the player. According to still another feature of theinvention, the player subsystem incorporates means for modifying thesession schedule received from the server subsystem by adding ordeleting specific programs and by altering the order in which theprograms are presented.

As contemplated by the invention, the player subsystem includes acontrol mechanism responsive to commands received from a listener todynamically alter the sequence and content of the programming materialactually presented. More specifically, the player may advantageouslyincorporate means for skipping the remaining content of any programbeing played at any time, or returning to the beginning of a particularsubject to replay its content. Each given program segment is preferablypreceded by a topic description segment, and the program skippingmechanism is the player is preferably adapted to automatically skip tothe next topic description, bypassing the intervening program content,whenever a skip command is receive when a topic description is beingplayed. Similarly, related topics (program segments) are sequentiallygrouped together by subject category, and a subject description programsegment advantageously precedes each subject collection. When the userissues a skip command at the time a subject description is playing, theplayer automatically skips all of the program segments (topics) withinthe described subject and continues by playing the next subjectdescription. In this way, the listener can rapidly skim through subjectcategories, one at a time, until a desired subject is reached, and thenallow the player to play topic descriptions one at a time until adesired topic (program segment) is reached.

In accordance with still another feature of the invention, means areemployed for identifying one or more discrete passages within anyprogram segment as being a “highlight,” and the player incorporatesmeans operative when the player is placed in a “play highlights” modefor skipping those portions of the content which are not highlights,thus enabling the listener to review only the key points of apresentation, or to more rapidly locate particular passages on interestwithin the body of a particular program segment.

According to yet another feature found in the preferred embodiment ofthe invention, a designated portion of a program segment may bedesignated as a hyperlink anchor from which, at the request of the user,the player jumps to another portion of the session sequence and beginplaying a different sequence of program segments. Means areadvantageously employed for generating an audible cue signal to informthe listener that a hyperlink anchor is being played, enabling thelistener to request that the link be executed. The hyperlink capabilitymay be used to advantage to implement cross references to relatedinformation, or to provide an audible menu of alternative programmingwhich the user may select merely by executing the link when the anchorpassage identifies other information of interest to the listener. In thepreferred embodiment, a stack mechanism is used to allow hyperlinks tobe called in nested fashion, so that a hyperlink may be executed from alinked program segment, with each “return” command from the user causingplay to be resumed at the program segment from which the last link wasperformed.

As contemplated by still another aspect of the invention, the playersubsystem includes means for identifying a program segment, or aparticular passage within a program segment, as a bookmarked item forease of reference later. In addition, the player system incorporatesmeans for accepting a dictated annotation from the user which associatedwith any bookmarked passage. This annotation mechanism may be used toparticular advantage when the program segments provided to thesubscriber include email or voice mail messages, since the bookmarkingmay be used to identify specific messages, or portions thereof, whichrequire later attention, and the annotation mechanism provides aconvenient mechanism for dictating replies and/or specifying actions tobe take in response to particular messages or portions thereof.

These and other objects, features and advantages of the presentinvention may be more completely understood by considering the followingdetailed description of a preferred embodiment of the invention. In thecourse of this description, reference will frequently be made to theattached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block schematic diagram of an electronic program andadvertising distribution system which embodies the invention;

FIG. 2 is a flow chart illustrating the principle steps followed in thecourse of the performing the information distribution functionscontemplated by the invention;

FIG. 3 is a flow chart illustrating the principle steps performed duringa playback session in the illustrative embodiment;

FIG. 4 is an information structure and data flow diagram illustratingthe manner in which programming is selected and accounting functions areperformed in the illustrative embodiment of the invention;

FIG. 5 is an information structure diagram illustrating the manner inwhich the program segments are dynamically selected and played inresponse to the user's preferences and control decisions;

FIG. 6 is a flow chart which describes a preferred procedure forpreparing the program content which is distributed to subscribers inaccordance with the invention; and

FIG. 7 is an information structure diagram illustrating the manner inwhich a narrative text file expressed in hypertext markup language(HTML) may be translated in to the combination of an audio speech file,a text file transcript, and a sequencing file used by the player tocreate a multimedia presentation.

DETAILED DESCRIPTION

The illustrative embodiment of the invention shown in FIG. 1 utilizesthe Internet to provide communications between a host computer indicatedgenerally at 101 and an audio player device illustrated at 103.

Subscriber Audio Player

The player 103 may be advantageously implemented by a conventionallaptop or desktop personal computer including a processor (the clientCPU 105), a time of day clock 106, and a data storage system consistingof both high speed RAM storage and a persistent mass storage device,such as a magnetic disk memory, the data storage system being used forstoring audio, text and image data at 107 and for storing usage data at109 which records the nature of the programming reproduced by the player103. The player 103 further includes a sound card 110 which receivesaudio input from a microphone input device 111 for accepting voicedictation and commands from a user and which delivers audio output to aspeaker 113 in order to supply audio information to the user. Theprogram data stored at 107 may advantageously include compressed audiorecordings and/or text (files of characters) which may be converted intoaudio form by conventional speech synthesis programs executed by theclient CPU 105.

The sound card 110 is conventional and preferably complies with therecommendations detailed in the Hardware Design Guide for MicrosoftWindows 95, by Doug Klopfenstein, Microsoft Press (1994), ISBN1-55615-642-1. The sound card 110 advantageously supports a 44 kHz,16-bit, stereo codec providing analog to digital conversion of audioinput signals from the microphone 111 as well as digital to analogconversion for programming directed to the speaker 111. The sound cardprovides external connections and hardware support for Microphone-In,Line-In, Line-Out, and Headphones-Out, with volume controlled by theplayer software (including volume level logging as discussed later inconnection with FIG. 3 of the drawings).

To support multimedia capabilities, the CPU 105 should meet or exceedthe capabilities of an Intel 486 DX2-66 computer to provide consistentlygood playback results and the sound card 110 should include a 16-bitdigital-to-analog converter for playback and a 16-bit analog-to-digitalconverter for recording. The sound card 110 should further support 8,11, 22, and 44 kHz waveforms. A frequency of 44 kHz is used forCD-quality sound and fractions of 44, such as 11 and 22, are often usedfor compressed waveforms meant to save CPU processing. Support for an 8kHz frequency should be in order to properly support Windows 95TrueSpeech™ compression, which is optimized for compression and playbackof human speech. Using TrueSpeech compression, programs containinglargely voice narrative data can be substantially condensed, and userscan record annotations and voice mail responses as discussed later.

In addition, the sound card 110 should be capable of reproducingdownloaded MIDI (Musical Instrument Device Interface) commands, enablingthe system take a MIDI data stream and produce sound according to thecompressed files consisting of digital sheet music instructions.Preferably, the sound card should support at least 16-voice polyphony(the ability to play several sounds at the same time), and polymessageMIDI, an capability included in Windows 95 that allows a sound card toreceive and batch-process multiple MIDI messages (such as Note On andNote Off). The sound card 110 should also a microphone port formicrophone 111, a speaker-out port (for one or two (stereo) unpoweredspeakers 113, and a headphone-out port.

The personal computer CPU 105 is also preferably connected to aconventional personal computer video display 118 and a standard keyboard119, as well as a pointing device (such as a mouse, trackball ortouchpad, not shown). The facilities provided by the operating system,such as Windows 95, typically includes multimedia support, as notedabove, as well as a standard WINSOCK TCP/IP stack and modem dial updriver software to support a SLIPP/PPP Internet connection, as nextdiscussed.

The player 103 further includes a conventional high speed data modem 115for receiving (downloading) the program information 107 from the remoteserver 101 and for transmitting (uploading) program selections andpreferences as well as usage data in the file 109 to the server 101. Toeffect these file transfers, the modem 115 is connected via conventionaldial up telephone SLIP or PPP TCP/IP series data communication link 117to an Internet service provider 121 which provides access to theInternet. The service provider 121 is in turn connected to the hostserver 101 via a high speed Internet link seen at 123.

Host File Server

The host server 101 provides a FTP server interface 125 which providesfile transfer protocol services to the player 103, a CGI interface 127which performs Common Gateway Interface script program execution inresponse to requests from the player 103, and an HTML interface 129which provides hypertext transport protocol (HTTP) World Wide Web serverfunctions to the connected player 103. The host server 101 stores andmaintains a plurality of data files including a program data libraryindicated generally at 130 consisting of a collection of compressedaudio program segments 131, announcement (“glue”) segments 132, textprogram segments 133, image segments 134, advertising segments 135 andprogram catalog information 137.

The compressed audio segments program segments comprise audio voice andmusic files which may be compressed using conventional compressionmechanisms suited to the data being compressed, such as TrueSpeechcompression for voice signals and MIDI files for compressed syntheticmusic reproducible by the sound card 110 as noted earlier.

Compressed voice programming in the database 131 may advantageously beaccompanied by text transcripts (files of characters) stored in the textdatabase 133. Similarly, images stored in the image database 134 may beused to provide a multimedia presentation which combines imagesreproduced on the display 118 of player 103 with concurrently presentedaudio at the speaker 113 and/or displayed text. Program segments whichpresent advertising, illustratively shown as being resident in aseparate database 135 in FIG. 1, may likewise consist of audio, textand/or image segments, as may the program segments which provideannouncements between program segments as well as audible and visiblemenu options which the user may select as described later.

As hereinafter described in connection with FIG. 5, each voice or textprogram segment preferably includes a sequencing file which contains theidentification of highlighted passages and hypertext anchors within theprogram content. This sequencing file may further contain references toimage files and the start and ending offset locations in the audiopresentation when each image display should begin and end. In this way,the image presentation may be synchronized with the audio programming toprovide coherent multimedia programming.

As contemplated by the invention, information which is available in textform from news sources, libraries, etc. may be converted to compressedaudio form either by human readers or by conventional speech synthesis.If speech synthesis is used, the conversion of text to speech ispreferably performed at the client station 103 by the player. In thisway, text information alone may be rapidly downloaded from the server101 since it requires much less data than equivalent compressed audiofiles, and the downloaded text further provides the user with readyaccess to a transcript of voice presentations. In other cases, where itis important to capture the quality and authenticity of the originalanalog speech signals, a text transcript file which collaterallyaccompanies a compressed voice audio file may be stored in the database133 from which a transcript may be made available to the user uponrequest.

The host server 101 further stores web page data 141 which is madeavailable to the player 103 by means of the HTML interface 128. The hostserver 101 additionally stores and maintains a user data and usage logdatabase indicated at 143 which stores uploaded usage data received fromthe store 109 in the player 103 via the Internet pathway 123 and the FTPserver interface 125. The user data 143 further contains additional datadescribing the preferences, demographic characteristics and programselections unique to each subscriber which is developed largely fromuser-supplied data obtained when users submit HTML form data via theInternet pathway 123 for processing by the CGI mechanism 127.

The host server 101 periodically transmits a download compilation file145 upon receiving a request from the player 103. The file 145 is placedin a predetermined FTP download file directory and assigned a filenameknown to the player 103. At a time determined by player 103 monitoringthe time of day clock 106, a dial up connection is established via theservice provider 121 and the Internet to the FTP server 125 and thedownload compilation 145 is transferred to the program data store 107 inthe player 103. The compilation 145 is previously written to thedownload directory by a download processing mechanism seen at 151 in theserver 101. Download processing, as described in more detail later,extracts from the library 130 data defining compressed program,advertising, and glue segments, and/or associated text program data,based on selections and preferences made by (or inferred for) the useras specified in the subscriber data and usage log database 143.

The download compilation file 145, though represented as a single filein FIG. 1, preferably takes the form of one or more subscriber andsession specific files which contain the identification of separatelystored sharable files. By way of example, the recommended order and theidentification of the program files making up an individual playbacksession are stored in a session schedule file (to be described in detailin connection with FIG. 5) which contains program identifiers of theprogram segments to be played during an upcoming session. The player 103downloads the session schedule file and then issues download requestsfor those identified program segment files which are not alreadyavailable in the player's local storage unit 107.

Usage data in the store 109 maintained by the player 103 is preferablyuploaded as a file bearing a predetermined file name indicative of theparticular subscriber and upload time and stored in a predetermined FTPupload directory. This upload advantageously occurs at the same time theplayer 103 establishes a download connection to the FTP server 125 asnoted earlier, and occurs prior to the download of the compilation 145.Because the upload data from the store 109 in the player 103 identifiesprogram segments desired by the subscriber, program segments newlyrequested by the user are appended to the compilation 145. Note that, intypical cases, programming in addition to the specifically requestedprogramming will be included in the download compilation, and thetransfer of that programming can begin immediately while the newlyuploaded user selections and other information are being processed asindicated at 153 to identify additional information to be included inthe download compilation.

As indicated at 161 in FIG. 1, the host server upload processingmechanism 153 also provides a number of reports, as described in moredetail later, based upon the record of actual player use by individualsubscribers and the community of subscribers as a whole. This reportprocessing is advantageously performed on a periodic basis in connectionwith financial and accounting functions including subscriber andadvertiser billing, content provider royalty payment accounting, andmarketing analysis processing.

It should be understood that numerous other information storage,processing and communications schemes may be substituted for thepreferred Internet server and PC client player architecture shown inFIG. 1. A dedicated host computer which communicates directly withclient stations via dial up telephone facilities may be used, andcellular radio, cable modem and satellite links may be used to providedata communications in lieu of the conventional SLIP/PPP telephone andInternet links shown in FIG. 1. To facilitate use of the system in anautomobile, a “player” computer may be linked to the Internet via alocal communications server computer via a radio or infrared link whenthe car is parked at the subscriber's home or office. The Infrared DataAssociation's (IrDA) wireless infrared (IR) standard provides a highlyeffective, low-cost communications pathway rapidly becoming a standardfeature in all notebook computers and PDAs. The IrDA internationalstandard provides interoperability among widely diverse systems,involves no governmental regulation, are provided at low cost, providehigh speed file transfers (e.g., 4 Mbs data rates), are small and can beeasily incorporated into portable computers of the type which may beused in a car or on public transportation. Alternatively, the filesdownloaded from the host may be stored on a replaceable media, such asan optical disk cartridge, which may then be inserted into a portablecomputer or simplified player for mobile use. A direct link between amobile client player (such as a laptop PC) may be implemented using theCellular Digital Packet Data (CDPD) service presently available in majormetropolitan areas to provide low-cost access to the Internet using theTCP/IP protocol, and provides the advantage that needed program segmentscan be downloaded while a session is in progress, eliminating the needfor a complete download before the mobile unit is disconnected from itsdata source.

Upload and Download Sequence—Overview

FIG. 2 illustrates the sequence of major events which are executed theprogram dissemination system contemplated by the invention.

As indicated at 203, an interested subscriber invokes programmingservices by first supplying personal information and initial programmingpreferences during an account initialization procedure. Preferably, asexplained in more detail later, account initialization is accomplishedby presenting the subscriber with HTML forms to complete and submit toCGC script programs which execute on the server to post subscribersupplied information into an initial user dataset. Based on theinformation supplied by the user, the server then compiles one or morefiles for downloading to the subscriber at step 207 which includeprogramming and advertising segments as well as additional data andutility programs needed by the player 103 to begin operation. Thedownload operation preferably occurs at a time established by the playerwhich establishes a dial up connection via the SLIP/PPP serialconnection 117 to the local Internet service provider 121 which providesan Internet connection to the host FTP server 125. The download file orfiles containing programming and advertising segments as well assubscriber specific data are designate by filenames provided by therequesting client/player 103 and moved from storage unit 145 utilizingthe FTP server 125 and the Internet connection into local storage at 107in the client/player 103. The filenames used to specify the files in theserver 125 may conveniently be formed from the program id value usedinternally by both the host and the player to identify and differentiatethe different program segments used.

The data downloaded includes a recommended program sequence file whichprovisionally identifies the order in which downloaded program segmentsare to be played, with the initial selection and sequence beingestablished based on user preference data by the download compilationprocessing mechanism seen at 151 at the server.

Before a playback session begins, as indicated at 211, the subscriberhas the opportunity to review and alter the provisional programselections and sequence established as a default by the downloadedinformation from the server. Utilizing the programming data and autility program previously supplied by the server, the subscriber mayalter the selection and sequence of program materials to be played,including altering the extent to which advertising will be played alongwith the selected programming.

At the request of the user, the sequence of programming defined by theprogram sequence file (the selections file illustrated at 351 in FIG. 5)is then reproduced for the listener. As contemplated by the invention,the player 103 includes controls which enable the user to easily movefrom program segment to program segment, skipping segments in a forwardor reverse direction, or to jump to a particular segment, and thus alterthe preprogrammed sequence. Nevertheless, when any given program segmentconcludes, the next segment which is specified as following the givensegment will begin playing unless the listener intervenes. Thus,although the segments are stored in randomly addressable locations inthe local mass storage unit, they are nonetheless played at step 212 inthe sequence established initially by the server and (optionally)modified by the subscriber, with the player providing the ability todynamically switch to any position in this sequence under the listenerscontrol. As indicated at 213 in FIG. 2, the listener may at any timereturn to the sequence editing step 211 to manually reorder the playingsequence if desired. As indicated at 215, a session usage log isrecorded during the playback session to identify every segment actuallyplayed, the volume and speed at which that segment was played, and thestart and end times.

At step 211, in addition to deleting and reordering items on the programschedule, the user may alter his or her selections and general subjectmatter preferences to control the manner in which the host assemblesprogram schedules for future sessions. When programs are included in acurrent schedule which are of particular interest, the subscriber mayassign a priority value to the scheduled program and, in that way,inform the host that the user has an interest in receiving moreprogramming in the same subject matter categories in which theidentified program is classified. When a program in a serializedsequence is assigned a new or different priority value at step 211, thehost system 101 assigns a corresponding Importance value to the programsegment record for each of the remaining unplayed programs in thatserialized sequence. Note that, by expressly approving advertisingsegments or categories of acceptable advertising in this fashion, thesubscriber may be granted a rate reduction since advertisers aregenerally willing to pay more for advertising directed to customershaving a known interest in a given subject.

At the conclusion of a session, subscriber is given the opportunity at217 to select programming which should be included in the nextprogramming download. To facilitate this selection process, additionalprogramming which fits the subscriber's indicated subject matterpreferences, along with additional programming which the server includesas being of particular interest, is identified in a catalog (asperiodically supplemented by a download file seen at 308 in FIG. 4) andpresented to the user in the form of a proposed program scheduletogether with a catalog of additional selections which may besubstituted or inserted into the proposed schedule. At step 219, theselections made by the user at 217 as well as the contents of the usagelog recorded at 215 are uploaded to the server as a requested file (seenat 301 in FIG. 4). This upload step may occur at the same time theSLIP/PPP dial-up connection is established by the player 103 toaccomplish the download, with the upload occurring first by an FTP filetransfer from the usage data store 107 to the FTP server 125 followed bythe downloading of files requested by the client 103 from the FTPserver.

In a addition to the downloaded catalog of available item s which may beviewed by the subscriber from the available downloaded information, theuser may re-establish an Internet connection to the HTML web server 129which presents HTML program selection and search request forms, enablingthe subscriber to locate remotely stored programming which may be ofparticular interest to the subscriber. When such programs are selectedin the HTML session, the user's additional preferences and selectionsmay be posted into the user data file 143 and the identification of theneeded files may be passed to the client/player 103 for inclusion in thenext download request.

Account Initialization

As contemplated by the invention, a subscriber account may beestablished by any user having a personal computer equipped to providethe capabilities needed to implement the player 103 as described above,together with Internet access via a service provider 121. Although aconventional modem dial up connections will perform satisfactorily, thetime required for uploading and downloading the necessary files may besubstantially reduced using higher speed access, such as an ISDN orcable modem link, when those services are available.

To establish a new account, a prospective subscriber may use aconventional web browser program, such as Mosaic, Netscape Navigator orMicrosoft's Internet Explorer, which executes in the client CPU 105 toestablish a conventional HTTP request/response dialog with server 101.The account initialization begins with the transmission of an HTML formfrom the web page store 141 which is completed by the user at thekeyboard (not shown) of the client CPU 105. The account information isthen transmitted to using a HTTP post method directed at a formprocessing CGI script executed by the server at 127 to place descriptiveinformation about the user in an assigned user data file as seen at 143.After the account has been established, utility programs and data may bedownloaded from the FTP server 125 to the client/player 103. Theseutility programs advantageously include programs which perform functionsincluding (a) program decompression, playback and navigation; (b)recording of a usage log file identifying the program and advertisingsegments played and the start time, ending time, volume level andplaying speed for each such segment; and (c) the selection and updatingof programming preferences and selections for future downloading.

The data fields supplied by a new subscriber at the initialization step203 may advantageously include the user's full name and billing address,credit card information or the like for use in subscriber billing; anddescriptive data about the subscriber (and others who may share thedownloaded material), such as: age, profession, sex, and marital status;the identification of subject matter categories of interest to thesubscriber, preferably with assigned weighting factors indicating thelevel of interest in each category. The subscriber may also indicategeneral preferences with respect to the including advertising, includingan indication of the amount of advertising which is acceptable to defraysubscription costs, ranging from fully advertised program

In addition, the subscriber may request and be presented with an HTMLform which lists available programs in a particular selected subjectmatter area, with a priority weighting factor pre-assigned to each inaccordance with the subscriber's previous specification for thatcategory. The form presented thus reflects the previously entered levelof interest weighting factor for each program based on its subjectmatter category, but permits the subscriber to override the suggesteddefault value on a program by program basis. Similarly, the subscriberis given the opportunity to override the default amount of advertisingdesired.

Advertising may be associated with particular subject matter categoriesas well as with particular programs. For example, an airline may wish toadvertise generally in connection with programming in the “travel”category whereas a particular resort hotel may wish to advertise only inconnection with a particular travelogue program for the region where itis located. Subscribers may wish to hear advertising in connection withthe programming in the travel category, but to eliminate commercialsfrom a daily program presenting “today's weather report.” The result isclearly advantageous for the advertiser, since advertising is focusedmore clearly on those having an interest in the subject matter and anexpressed willingness to listen to commercial messages, while thesubscriber is able to receive advertising which may be regarded asuseful while eliminating unwanted advertising.

Because personal data describing each subscriber's subject matterinterests is available, along with personal data (age, marital status,zip code, etc.), particular advertising segments may be directed to onlythose subscribers having a likely interest in the goods or servicesadvertised. This targeted advertising need not be presented at any timeduring the playback for the designated subscriber and need not be timedfor presentation with particular programs. For example, a subscriberindicating an interest in travel programming may be supplied withadvertising from an airline at any time, and not necessarily concurrentwith selected travel programming.

Because a subscriber may have a particular interest in or enjoy someadvertising, and may have a particular dislike for other specificadvertising, the user may advantageously be presented with a listing ofadvertising organized by advertiser and subject, providing thesubscriber with the opportunity to select additional desired advertisingon the list while suppressing others. Since the voluntary acceptance ofadvertising preferably reduces the programming charge to the subscriber,the utility program which executes on the client CPU 105 to enableprogram and advertising selection, sequencing and editing preferablyprovides an advisory indication to the subscriber of the charges orcredits to be accrued if the currently programmed sequence is played.This feature enables subscribers to better control the costs of theservice by accepting sufficient advertising content to reduce thesubscription cost to an acceptable level. Subscribers may also set aplayer system variable to a value indicating the subscription costs perunit time that the subscriber is willing to accept, and the player 103can then automatically insert advertising segments between programsegments in sufficient quantity to achieve a net charge at the desiredlevel.

Player Operation

The playback operation indicted generally at 212 in FIG. 2 isillustrated in more detail in FIG. 3.

In order to limit access to the downloaded programming materials to thesubscriber or persons authorized by the subscriber, the playback utilityprogram executing on the client CPU 105 (FIG. 1) advantageously beginsthe session by requesting the entry of a password as indicated at 231.The entry of this or a different password may also be required foraccess to the utility programs used to modify the subscriber's personaldata, future program selections, and current program selections andsequencing. Similarly, information which might be revealed concerning anindividual subscriber by the host server 101 is advantageously passwordprotected.

As with all Internet transactions, the actual data transmissions ofinformation other than publicly available programming may also beencrypted. To this end, the client and server ends of the pathway mayexchange public keys to enable encrypted transmission using conventionalRSA encryption. By placing the decryption capability within thecapability of the playback unit which is capable of directing decryptedcontent only to the system's speakers and display screen, but not to afile, the system insures that the internal usage accounting mechanismcannot be bypassed by reproducing downloaded program segments usingother means. In addition, and as a part of this secure accountingarrangement, the host system can be programmed to require the receipt ofan uploaded usage log (from which subscriber and advertising charges andcontent provider payments can be determined) before releasing additionalprogramming materials for downloading from the FTP server 125.

As described in more detail later in connection with FIGS. 4 and 5, thesequence of program segments to be presented to the user is formed intoa schedule file (seen at 307 in FIG. 4) consisting of a sequence ofprogram segment identification numbers which are used to compile asequencing file, called the selections file, illustrated at 351 in FIG.5, which contains more detailed information about the sequence of eventswhich occur during playback. The player obtains information from theselections file which identifies the individual program segments to befetched from mass storage and played for the user, as well as thesegment identification information which is recorded in a usage loggingfile in the manner illustrated in FIG. 3.

As indicated at 233, the playback session begins with the presentationof an audio (and/or displayed) menu which allows the user to jump to anyprogram segment within that sequence to start (or resume) playback at235, or terminate the session at 236.

The playback operation itself continues from the designated playbackpoint in the selections file (seen at 351 in FIG. 5) which follows aprogram sequence initially created by the host server and downloadedwith the program segments themselves, and then (optionally) modified bythe addition, deletion and re-sequencing of segment identifiers asdiscussed earlier in connection with step 211 in FIG. 2. Note howeverthat, if the user elects to have advertising segments automaticallyinserted between program segments to achieve a predetermined cost level,that insertion occurs under the control of the playback mechanism at 235such that advertising segments not identified in the selections file maybe added or advertising segments specified in the selections file may beautomatically skipped.

As playing progresses, the current playback position may beadvantageously indicated by a variety of means. In the most simple form,the current playback position within the session file of selections(discussed in more detail in connection with FIG. 5) may be indicated bya simple numerical readout indicating the position on a scale of 1-100.In this way, a user listening to the programming in scheduled order isprovided with an indication of the duration of programming remaining tobe played. In a player implemented by a personal computer provided witha screen display, the current playback position may be advantageouslyindicated by displaying the program segment topic descriptions in ascrolling listing, with the description of the program currently beingdisplayed being highlighted. The scheduled duration of each programsegment may be displayed, along with the elapsed time remaining to beplayed in the currently playing segment, to enable the user to moreeasily determine when to skip the remainder of the currently playingsegment. When such a concurrent visual display is available, means mayalso be included to respond to the users selection of a given program onthe scrollable listing by means of a mouse or the like, and thenautomatically continue the play at the beginning of the program segmentthus selected.

Each time the playback begins a new programming, advertising orannouncement segment, the segment start time is recorded in the usagelog file stored at 109 (FIG. 1). Each usage log record contains aprogram segment identification number (ProgramID) obtained from theselections file as well as a start time and date stamp encoded into a 32bit date-time value, a volume level setting indicating the volume atwhich the player was set at that time, and a playing speed valueindicating the playing speed or playing being used.

As indicated at 237 in FIG. 3, each time a new program segment isstarted, a new segment handling procedure is executed at 239. If theuser desires to have advertising inserted to defray the costs of thesubscription, the current actual cost per unit time is calculated andcompared with the desired cost per unit time. If the cost is determinedto exceed the desired level, an additional advertising segment isstarted; otherwise, the next program segment in the program sequence 214is played. In either case, the segment id of the newly starting segmentis recorded in the log file along with the start time for that segment.Note that it is unnecessary to record the end time for the prior segmentsince it is the same value as the start time for the next segment. Whenplay is concluded, a terminating record indicating the time of turnoffis recorded to enable the duration of the last segment to be calculated.

Recording Volume and Playing Speed Changes

As indicated at 251, if the user changes the volume level or playbackspeed by a significant amount, a new record is posted to the usage logat 253, indicating the continuation of the last program at a new volumelevel (thus producing two records in sequence having the same programsegment ID numbers but having differing start times and volume levels).The user adjusts the volume by means of a software control displayedwhen the player is active. The user adjusts the control using the mouseor keyboard to adjust the volume. When the volume control experiences achange in level greater than a predetermined deviation, it sends amessage to the player routine at 251 to cause the new volume level to berecorded at 253. New volume settings do not affect the program sequenceand the recording of the volume level change takes place transparentlyto the user. Likewise, when the user changes the playing speed, orswitches to highlight mode, the new playing speed setting is recorded(using the PlayingSpeed variable in a Usage Record, to be discussed)

The cost accounting program which calculates subscriber charges and feesto advertisers may thereby treat volume levels below a predeterminedthreshold level, or playing speeds in excess of a certain level, asbeing equivalent to skipped programming. In addition, if a subscriberreduces the volume on selected programs or programs in particularsubject matter categories, frequently increases the volume for otherprograms or subject matter categories, or sets the playing speed to playhighlights only of other programs, that data can be used to inferpreferences and dislikes which can be used to better select desiredprogramming to be included in future download compilations.

User Playback Controls

The player mechanism seen at 103 includes both a keyboard and amicrophone for accepting keyed or voice commands respectively whichcontrol the playback mechanism. As indicated at 261, the receipt of acommand, which may interrupt the playback of the current selection, andthe character of the command is evaluated at 262 to select one of sixdifferent types of functions.

The player 103 responds to the first command, “Accept” indicated at 263,by temporarily suspending the playback in order to accept a spoken“comment” from the user which is recorded as indicated at 264. After theconclusion of the comment, control is returned to 261 to test foradditional commands before playback is resumed at 235. As described inmore detail later, comments dictated by the user are saved and lateruploaded to the host system where they exist as program segments. Byallowing the user to dictate and record comments, the system provides anumber of useful capabilities, including posting comments and messagesto the host (requests for help or additional information), postingcomments and messages either privately or publicly to the originator ofa program segment being played, thereby enabling private interchanges tooccur between users, to enable the interchanges to take place inpublicly available threads analogous to the UseNet and Listserynewsgroups employed on the Internet to facilitate public discussionsrelated to predetermined topics. In addition, the ability to accept andupload user-generated comments and information provides a valuablemechanism by which the user can evaluate and comment on the programmaterial being provided by the host. As described later in connectionwith FIGS. 5 and 7, the mechanism seen at 263 and 264 for introducing apause in the session playback while a voice response or comment from theuser is recorded can also be employed to produce program generatedprompts which request information followed by automatic responserecordings, thereby enabling the system to be used to collect data,program evaluations, and other information from the user.

A first command, “Go” indicated at 265, causes the player to make animmediate shift to a different program segment. For example, the spokenvoice command “FIVE” can indicate a request to go to a predeterminednumbered program segment while the spoken command “NEWS” could switch tothe subject announcement segment for news programs. Alternatively, amouse click on a screen-displayed menu of items, or a push-button on ahand controller connected by an infrared link to the player computer,could similarly be processed as a command to go to a predeterminedprogram segment associated with that command signal. In such cases, thesystem records the start of the new segment on the log file (seen at 215in FIG. 2) at 267 and switches the current playback position in theprogram sequence file 214 to the new setting at 269, and the playbackcontinues at 235.

In the preferred arrangement, described in more detail in conjunctionwith FIG. 5 of the drawings, the program being played may containpassages which relate to other program segments in the compilation.These passages may be indicated by direct announcement, such as: “Say‘Go’ when any of the following automotive companies are named to obtainadditional information: . . . Ford . . . General Motors . . . Chrysler .. . Honda . . . ” Alternatively, an audible cue signal, such adistinctive tone or chime, might immediately precede a passage whichanchors a link to another program segment. Players equipped with stereoaudio output capabilities can make cues distinctive by playing cuedannouncements in one stereo channel, with or without a supplemental cuesignal in the other channel. When a cue signal indicates a hyperlinkpassage, a simple “Go” voice command causes the player to reset to a newlocation from which playing continues until a “Return” command, seen at266, causes the player to return to the original sequence.

As discussed later in connection with FIG. 5, hyperlinks of this typemay be used to identify program segments which are not available in theplayer 103 because they were not downloaded for inclusion in a scheduledsession. In that event, the “Go” handling routine seen at 265 posts arecord to the usage log containing the ProgramID of the requested butunavailable segment so that the requested segment can be included in theRequested file 301 seen at 301 in FIG. 4.

When a communications pathway such as an Internet or cellular phone linkis available to connect the player 103 to the server, an immediaterequest may be sent to the server to download a needed but locallyunavailable segment. In that case, the downloading and playing mayproceed concurrently by placing the downloaded information into a memorybuffer to which the downloaded program segment is written as it isconcurrently read for reproduction as described U.S. Pat. No. 5,371,551issued to James Logan and Daniel F. Goessling. To eliminate breaks inthe program sequence, the player 103 may advantageously perform alook-ahead operation, sending a file request to the file server via thecommunication link by pre-scanning the program sequence file 214 toidentify program segments to be played which are not in local storageand requesting those segments before they are needed.

Because announcement or “glue” segments are frequently repeated indifferent program segments, these segments are preferably retained inlocal storage by the player to avoid the need to be downloaded. Theplayer advantageously processes the usage file at the end of eachsession and tags each program segment which has been played as beingeligible for replacement to make room when necessary for incomingsegments Announcement segments, however, are preferentially retainedeven though they have been played because of the higher probability theymay again be included in upcoming session schedules.

The third command, the SKIP command indicated at 275 in FIG. 3, causesthe player to advance to the beginning of the next program segment inthe program sequence, recording the start of the next sequence at 267and resetting the playback position at 269. If the program segment hasbeen subdivided (e.g. into paragraphs), the SKIP command causes theplayer to skip forward to beginning of the next subdivision within thatsegment. If desired, SKIP commands may be subdivided into two types, aSKIP TOPIC command and a SKIP SUBJECT command. When programming materialsuch as news reports are grouped into topics within subject categories,as described later in connection with FIG. 5, a SKIP SUBJECT commandallows the user to skip over all program segments within that subjectand resume playback at the leading description of the next subject. Incontrast, the SKIP TOPIC command always advances to the next topic(program segment or program segment subdivision) in the sequence. Ifdesired, the SKIP TOPIC command can produce a jump to the next programsegment or subdivision which does not contain advertising, making itunnecessary for the listener to listen to advertising while scanning theprogram sequence for the next desired program segment.

The BACK command indicated at 278 operates like the SKIP command but inthe reverse (“rewind”) direction. Similarly, the BACK command may besubdivided into two commands, a BACK SEGMENT and a BACK SUBJECT command,which respectively reset the playback point to the beginning of theprior segment or the beginning of the prior subject description. Notethat, after any given segment has played for a predetermined amount oftime, the BACK command should reset the playback to be beginning of thecurrent segment or topic respectively, allowing the user to start thecurrent segment or topic from the beginning unless the playback point isalready near the beginning, in which case the transition is made to theprior segment. The system responds to BACK commands by resetting theplayback point to the desired point in the sequence and recording thestart time, volume setting and new program segment ID in the log file asindicated at 267.

In the preferred form of the invention described in more detail inconnection with FIG. 5, the context sensitive SKIP and BACK commands areused instead of the SKIP TOPIC, SKIP SUBJECT, BACK TOPIC and BACKSUBJECT commands discussed above. In the preferred arrangement, theprogram materials include subject and topic announcement programsegments in addition to the program segments (both programming andadvertising). When the user issues a SKIP or BACK command while theplayer is playing a subject or topic announcement, the player skips theentire subject or topic being announced and moves to the next subject ortopic announcement respectively, automatically bypassing the interveningprogram segments which comprise the skipped subject or topic.

The fifth command, a “MARK” command at 280, is used to place a“bookmark” into the usage log which identifies a program segment, or aportion of a program segment, which the listener wishes to designate forfuture use. In its simplest form, the bookmark recording functionindicated at 281 may simply record a bookmark and the Program_ID of thecurrent program segment into log file. By bookmarking a program segment,that segment may be recalled by the subscriber and all or part of itsaved for later use in local storage, from which it may be reproduced,forwarded as an attachment to an email message, and the like.

More elaborate bookmark functions which may be readily incorporated intothe system if desired include the following:

-   -   Dictating or keyboarding an annotation at a predetermined        position in the bookmarked program segment, the annotation being        saved in local storage so that, when the bookmarked program        segment is reproduced, it will include the annotation. The        bookmarked program segment and the annotation may then be saved        as a unit for future reference or forwarded to another person.    -   Bookmarked program segments, or annotations to bookmarked        program segments, may be used in conjunction as an auxiliary        audio voice mail and email handling system in which a        subscriber's email and voice mail items are organized as topics        in the playback session, enabling the subscriber to bookmark        particular incoming messages (program segments) for further        attention, or to dictate voice mail responses, or responses that        can be converted to text form by a human typist or by a voice        recognition system. This aspect of the present invention allows        the subscriber to review and respond to incoming email and voice        mail messages while commuting or traveling to more productively        utilize travel time. Voice annotations may be stored in separate        files which are uploaded to the host with the usage file and        keyed to the program segment passages which they annotate by        records in the usage log file.

The sixth command type, the “MENU” command indicated at 283 in FIG. 3switches the player to a predetermined menu program segment, records thestart of a menu mode state in the log file at 285 and places the playerin the menu mode at 233. Using a hands free voice command system, theplayer may reproduce a menu program segment in which a sequence ofoptions are enunciated on the system's audio output speaker with shortpauses between the recited options. By providing the voice command “Go”during or shortly after a desired option, the user may cause the systemto branch to that selection. Menu options of this type may beconveniently implemented using the hyperlink capability described laterin connection with FIG. 5. Alternatively, as noted earlier, the menu ofoptions may be displayed on the screen with the desired playback pointbeing selected using the keyboard or a pointing device. In all cases,each transition to a new program segment is recorded into the usage logfor later uploading to the server and subsequent processing.

Program Compilation & Billing

FIG. 4 illustrates the principle data processing steps and informationstructures employed by the preferred embodiment of the invention tocompile programming information personalized to the preferences ofindividual subscribers, to perform accounting functions which producebilling charges to subscribers and advertisers, and to determine royaltypayments due to content providers.

The program, advertising and announcement segments to be made availableto an individual subscriber include those program selections which thesubscriber chooses from the supplied catalog of recommended programs, oradditional selections chosen during a dial-up dialog with the host, asdescribed above in connection with step 217 seen in FIG. 2. Theselections made by and uploaded from the subscriber take the form of afile (sequence) of 32 bit integers, each integer (ProgramID) designatinga particular program segment. This file of integers is placed in arelational database Requested Table seen at 301 in FIG. 4, with each row(record) in the Requested Table being an identification number whichspecifies a corresponding record (row) in a database table 303 calledthe Programs Table. The Requested Table 301 includes not only expressrequests from the user based on catalog selections but also requestswhich result from failed hyperlink requests which occur when thelistener requested hyperlinked information during the session which wasunavailable in local storage at the player. The program segments (whichinclude programs, advertising and announcements) have a plurality ofattributes which are described in the data fields of each record (row)in the Program Table 303. The following Pascal type declarations definethe content of each record in the Programs Table 303:

Type Classtype = (advertisement, program, announcement); Program_Segment= record ProgramID: integer; { unique key } ProviderID: integer; Class:Classtype; URL: pchar; Created: datetime; SubjectDesc: integer;TopicDesc: integer; GroupID, Episode: integer; CommentOn: integer;Subjects: array[0..15] of integer; Importance: array[0..15] of integer;Youngest, Oldest, male, female: byte; HouseLow, HouseHigh: byte;Duration: integer; Plays: integer; TotalTime: double; PlaysRate,TimeRate: integer; Timeliness: integer; end;

Each Program_Segment record in the Programs Table 303 is identified by aunique key integer value, ProgramID, which is the primary key value uponwhich the Programs Table 303 is indexed and accessed. TheProgram_Segment records in the Programs Table 303 are relationallylinked using the ProgramID key to other tables including:

-   -   the Requested Table 301 discussed above,    -   a Schedule Table 307 which contains the recommended sequence of        program segments for the next playback session,    -   a NewCatalog Table 308 which contains the identities of new        available program selections to be added to the subscriber's        catalog of available programming, and    -   an Advertisements Table 311 containing entries which describe        advertising program segments to be brought to the attention of        the subscriber.

The relational database system employed by the preferred embodiment ofthe invention further includes a Subscribers Table 313 which containsinformation describing each subscriber, a Content_Providers Table 315containing information about each person or firm which suppliesroyalty-bearing information for dissemination to subscribers, and anAdvertiser Table 317 which contains information about each advertiserthat provides advertising program segments to subscribers. Mailingaddresses and other information for subscribers, content providers andadvertisers is contained in a single Account Table 321 to simplify thedata structures needed.

A Usage_Log Table seen at 333 is uploaded from the subscriber, typicallyat the same time the express program requests in the Requested Table 301are transferred, and processed at 350 to update the Subscribers Table313, the Content Providers Table 315, the Advertisements Table 311, thePrograms Table 303, and the Requested Table 301 as described below.

Program Schedule Generation

In accordance with the invention, the host server receives andsupplements the user's initial selection of a sequence of desiredprograms, first by adding the program selections specified in failedhypertext requests as indicated by the Usage_Log Table 333 during usagelog processing at 350, and then by adding advertisements, announcementsand additional program segments tailored to the subscriber's knownpreferences as indicated at 340 in FIG. 4, thereby producing therecommended Schedule Table 307 which is transferred to the subscriber,along with program segments, during the download transfer. Indeed, ifthe subscriber provides no selections at all, the host will prepare aSchedule Table 307 containing program segment selected entirely by thehost on the subscriber's behalf. The programs, advertising andannouncement segments which are added to the Request Table 301 to formthe Schedule Table 307 are determined by a matching procedure 342 whichmay be better understood by first considering the content of the datastructures which provide data utilized to make those selections.

The Programs Table 303, as noted above, contains Program_Segment recordswhich describe the nature of each programming, advertising andannouncement segment in the library which is potentially reproducible bythe player 103. As illustrated by the type declaration above, eachProgram_Segment record specifies the account number (ProviderID) of theadvertiser or content provider if any who may be charged or compensatedfor the actual playing of the program segment by subscribers. The recordfurther contains a Classtype variable Class which indicates whether thissegment is an advertisement, a program, a comment or an announcement.

The Class variable may also used to further subclass each programsegment; for example, program segments which hold user-recorded commentsmay be designated as being “public” comments made generally available toall subscribers, “private” comments to be directed solely to theprovider of the program segment commented upon, and “host” comments tobe directed to the host system.

The Program_Segment record's URL field specifies the location of thefile containing the program segment in the file storage facilityindicated at 304 in FIG. 4 (i.e., normally on the FTP server 125 seen inFIG. 1, but potentially including storage areas on the web server 141 orat any other accessible location on the Internet). In addition, thesubscriber may wish to designate for future play a program segmentalready loaded into the player 103 by virtue of a prior download. Thesubscriber may elect to include an already loaded file because it wasnot reached in a prior playback session or because the subscriber wishesreplay the selection. In that event, the ProgramID of such a selectionis nonetheless included in the uploaded selection list (Requested Table301), recognizing that at the time of actual download, the player 103will only request the transfer of those program segments not alreadypresent in local storage. The uploaded Requested list 301 shouldaccordingly be understood to be indicative of the requested content of afuture planned playback session and not necessarily a listing ofprograms to be downloaded. The selection of files to download ispreferably made by the player which issues FTP download requests fromthe server by specifying the URLs of the needed files.

The Created field contains a timestamp value specifying the data andtime of day the program segment was created. In Created field allowsuser or host to select program segments by date and permits the listingof segments in chronological order in program catalog listings.

The Program_Segment record further contains a SubjectDesc field and aTopicDesc field, both of which take the form of ProgramID integers whichidentify other program segment records which contain detailedinformation on audio announcement and displayable text descriptions ofsubjects and topics. The descriptive text files for subjects and topicsare displayable by the player 103 as part of descriptive catalog entrieswhich enable the user to choose desired segments. Together, the subjectand topic program segments provide a hierarchical catalog listing whichprovides the descriptive information about the associated contentsegments which enables the subscriber to make informed selections. Thetext specified by the SubjectDesc and TopicDesc fields may be searchedusing conventional keyword searching techniques to permit the subscriberto locate and identify particular programming of interest from thelocally stored catalog or, in a dial up CGI interaction with the host,to list and select programs from the larger library available on theserver.

Serialized Programs

As contemplated by the invention, programming may include serializedsequences of programs. A given program segment may represent an episodein a series which is selected as a group by the subscriber, or asubscriber may select an individual program in a serial sequence and thehost may then further installments or related programs within the seriesto the catalog or session content thereafter sent to the subscriber. TheProgram_Segment record contains a GroupID field which specifies theseries as a whole, and an Episode integer field specifies the positionof the given program segment within the serialized sequence. When aserialized sequence is requested, the host may download the entireseries in one download for playback at requested intervals, or less thanall of the episodes when all are not yet available or when it isdesirable to limit the total download content. When a subscriber selectsand plays a given program segment, as indicated in the usage log,without having expressly selecting the entire series, the host may thenadd the next installment to the catalog or the next proposed session. Ifdesired, a hyperlink (to be described) may be placed at the conclusionof each installment which specifies the next installment as the linkedprogram segment. In this way, the listener may request that the nextinstallment be played immediately (if it is available) or included inthe next installment (if it is unavailable and the hyperlink fails).

The usage log may be employed to insure that the subscriber has anopportunity to hear episodes that may have been skipped. By monitoringthe usage log, if an episode included in any given proposed session wasnot in fact played, the host may include it in the next proposed sessionas well. Note further that the serialization mechanism which has beendescribed can be used to provide serialized advertisements to asubscriber, insuring that a subscriber does not hear a particular adtwice and further insuring that the advertising is presented to thesubscriber in the intended sequence.

In addition, the serialization mechanism may be used to providesequential presentation relationships between related programs. Forexample, if a subscriber indicates an interest by selecting and actuallyplaying a program on an evolving topic; for example, a news story aboutthe America's Cup yacht races, further new stories on that topic may beassigned the same Group ID number so that they are automatically routedinto the subscriber's catalog or program session if space is available.

Fields Supporting “Comments”

Serialized programs are related to, but should be distinguished from,the parent-child relationships that exist between program segments andthe annotations and comments made on those program segments by users. Asnoted earlier with respect to the Accept command seen at 263-264 of FIG.3, the player 103 of FIG. 1 permits the user to create an “annotation”or “comment” (typically in the form of a recorded audio message or akeyboarded text message) which is uploaded to the host 101 and stored asa program segment. The CommentOn field of the Program_Segment recordcontains the Program_ID of the program segment commented on, theProvider_ID field identifies the subscriber generating the comment, theCreated field specifies the date and time when the comment was recorded,and the default values of the subject matter fields (discussed next) arecopied from the subject matter fields of the program segment beingcommented on. These field entries provide a mechanism for supporting thecomment handling features which are described in more detail below underthe heading “Comment Handling.”

Program Selection

The Program_Segment record further includes a Subjects field which is anarray of 16 integers, each of which may be a non-zero code valueindicating a predetermined subject matter categories, allowing eachprogramming segment to be matched against like codes specified as beingsubjects of interest by the subscriber, as well as codes indicatingsubjects to which advertised goods and services may relate.

The Program_Segment record also contains an Importance field which isalso an array of 16 integers which (at least initially) holds an integercontaining the reviewer/editor's assessment of the “importance” of theprogram segment relative to the subject matter code specified in thecorresponding cell in the Subjects array. Thus, if Subjects [7]=12345and Importance[7]=231, this program segment has been assigned aimportance level of 231 with respect to the subject specified by code12345. Another segment may also be relevant to the same subject, butwith a different level of importance to that subject. These fields maybe used by the host as a weighting factor used to route programs ofgreater probable interest to the subscriber. Note also The “importance”value associated with any given program may also be adaptively alteredbased on the actual use as reflected by the usage logs and bysubscribers' catalog selections. By way of example, program segmentswhich are started but frequently skipped while in progress may havetheir importance value decreased while program which are frequentlyselected from the catalog and listened to may have their importancevalues increased. In this way, the system adaptively learns, for eachcategory or programs, which programs subscribers have found to be ofinterest and which ones were seldom used. Serialized programs(identified by a common Group ID) may be assigned importance valuesbased on the actual usage of earlier episodes in the same series. Thus,when a series proves to be popular based on repeat selections of itsepisodes, all episodes (including those not yet issued) may be assigneda higher importance value.

The Youngest and Oldest fields (each storing a byte value 0-255)contains an indication of the age range to which a particular programsegment should appeal. Similarly, the byte values Female and Male allowthe entry of an estimate of the relative interest of a given program tothe different sexes: thus, a program devoted to sports news could beassigned the values Female=60, Male=170 where the value 127 wouldindicate gender-neutral content. The MaritalStatus field is a singlecharacter (“S”=single, “M”=married, “W”=widowed, “D”=divorced).

The fields HouseLow and HouseHigh represents a range of household sizesrange that may have a special interest in the program segment. Thus,programming directed to family interests may be directed to subscriberswho are married with a household size equal to 3 or more.

The Duration field of the Program_Segment record specifies the durationof the program segment expressed in seconds. The Plays field is anaccumulator field which is incremented by incoming Usage_Log records toreflect the total number of times a given program segment has beenactually played by all subscribers. Similarly, the TotalTime valuerepresents the total time a given program segment has been actuallyplayed by users. Together, these records can be used to determine theadvertising fee due from the advertiser, or royalty amount payable tothe content provider (the advertiser or content provider being specifiedthe ProviderID field) for the use of this segment.

The Program_Segment record contains two signed integer values, PlaysRateand TimeRate, permitting an advertising charge or royalty payment(Amount) to be calculated as a value calculated by the executableformula:

Amount:=(Plays*PlaysRate)+(TotalTime*TimeRate)

If PlaysRate=0, the amount of the royalty or advertising fee for actualuse of the segment can calculated based solely on the actual timeduration of the played segment (so that little credit or charge isassigned if the segment is begun but then skipped). Alternatively, ifTimesRate=0, the charge can be based solely on the number of timesplaying the segment was commenced, which may be deemed appropriate whenit may be considered the responsibility of the advertiser or the contentprovider to hold the user's attention once a segment begins. Note that,as usage records are posted to increment the Plays and TotalTime fieldsin the Program_Segment records, as described later, any program segmentwhich was played for less that a predetermined minimum amount of timemay be disregarded, enabling the subscriber to “surf” through selectionswhile listening to minimal information per segment without incurringsubscription charges or generating advertising fees or royalty payments.

Program segments are selected for inclusion in the output Schedule Table307 and/or the NewCatalog Table 308 by comparing the content of thePrograms Table 303, the Subscribers Table 313, and the AdvertisementsTable 311. The fields contained in the Subscribers and AdvertisementsTables are set forth in the following Pascal record type declarations:

Account = record AccountNo: integer; { Unique key } Name, Title,CompanyName: pchar; Addr1, Addr2, City: pchar; State: string[2]; Zipcode, AreaCode, Phone, Fax, Email: pchar; end; Subscriber = recordAccountNo: integer; Birthdate: Date; Sex, MaritalStatus: Char;HouseholdSize: byte; Interests: array[0..15] of integer; TopChoices,ChoiceCounts: array[0..15] of integer; ChargeLevel: byte; DataRate:Integer; Capacity: Integer; WeekDays: array[0..6] of Compilation; end;Advertisement = record ProgramID: integer; AccountNo: integer;DemographicMatch: function_id; DemographicWeight: byte; Earliest,Latest: datetime; Subscribers: integer; Repeats: byte;  end;

The Accounts Table seen at 321 in FIG. 4 is indexed by a key valueAccountNo which is unique to each of its Account records. The fields ofthose records contain name, mailing address, telephone, fax and emailinformation for all subscribers, advertisers and content providers in asingle shared file. A person or firm specified by a record in theAccounts Table could simultaneously be a subscriber, advertiser and acontent provider, in which case the same AccountNo key value wouldappear in each of the three tables: Subscribers 313, Content Providers315 and Advertisers 317. Prospective or inactive subscribers, contentproviders and advertisers may also be described by entries in theAccounts Table which are not referred to in any other tables.

Additional information about each active subscriber is contained in theSubscriber record indexed by AccountNo (a key shared with the AccountsTable). The Subscriber record specifies personal information about thesubscriber, including birth date (from which age may be determined),sex, marital status, and household size, all of which may be of use inbetter selecting program material of possible interest which should bebrought to the attention of the subscriber.

Each Subscriber record further includes two arrays of integers whichindicated the subscriber's subject matter preferences. The Interestsarray contains 0 to 16 integers each indicating a subject mattercategory of interest to the subscriber, the integers having the samemeaning and being take from the same category listing as the integersplaced in the Program_Segment record's Subject array. These integers areplaced in the Interests array in response to the subscriber's indicationof subject matter preferences when the account is established asindicated at 203 in FIG. 2 or at any time thereafter when the subscriberelects to modify the stated preferences at step 217 in FIG. 2.

A second array of 16 integers called TopChoices is an ordered list ofthe same subject matter integers; however, in this array the subjectmatter integers are listed in order of actual playing frequency asindicated by the parallel array of ChoiceCounts integers. For example,the subject matter integer 321 in TopChoices[3] and the count 18 inChoiceCounts[3] indicates that 18 selections had been played in thecategory 321 which was the fourth most-frequently played category. TheChoiceCounts array is modified whenever the usage log indicates that aselection in a particular category has been played by that subscriber.As a consequence, the TopChoices and ChoiceCounts arrays provide anindication of the subscriber's interests as indicated by his or heractual use of the player.

The ChargeLevel field in the Subscriber record indicates thesubscriber's willingness to accept the insertion of commercial messagesinto the programming in order to defray subscription costs. AChargeLevel value of zero indicates that the subscriber desires to paythe minimum charge and correspondingly is willing to accept sufficientadvertising content to achieve that goal. At the other extreme, aChargeLevel value of 255 indicates that the subscriber wishes toeliminate all commercial messages except those specifically requested.

The DataRate field indicates the rate at which information can bedownloaded to the subscriber over the available communications link(typically dependent on the capacity of the modem used by thesubscriber). The DataRate field is initially established frominformation supplied by the subscriber when the account is established(at step 203 in FIG. 2) but is thereafter altered to reflect actualaveraged transmission rates experienced during download operations.Similarly, the Capacity field indicates the available mass storage filespace available for program data in the player store (seen at 109 inFIG. 1). This value is initially supplied by the subscriber duringaccount initialization, automatically reduced whenever the utilityprograms executing on the processor 105 detect less space available, andincreased whenever the subscriber consents to the allocation of moreavailable space when the utility programs detect that space is availableand that additional space could be beneficially utilized given thedownload time available and the subscriber's desired session lengths.

Desired session lengths are contained in seven records each of typeCompilation as defined in the following record definition:

Compilation = record Earliest, Latest: datetime; PlayMinutes, Longterm:Integer; end;

Each Compilation record describes the download requirements for aspecific day of the week and contains fields specifying the earliest andlatest times of day when download can be begun, with the latest downloadtime being at least a predetermined time in advance of the sessionstart. In this regard, it should be noted that playback and download canoccur concurrently, with the Schedule Table being downloaded first, theNewCatalog Table being downloaded second, program segments specified inthe Schedule Table which have not previously been downloaded beingtransferred third (in the order of the expected presentation as statedin the Sequence Table), with program segments selected by the subscriberfor future sessions being downloaded last as download time permits. Inaccordance with the invention, it is desirable to download theequivalent of a full session's programming in addition to the currentlyscheduled session programs so that, in the event of a temporarycommunication link or host failure, programming will be nonetheless beavailable. In installations which utilize download information to aremovable media cartridge or a transportable player which is then playedback in an automobile or elsewhere, and hence disconnected from the datalink to the host, it will of course be necessary to complete thedownload prior to the disconnection, meaning that the Latest field inthe compilation record should be a time which is in advance of theearliest expected session start time by a duration equal to the maximumexpected download time. Because the subscriber may wish to use differentdownload timing on different days of the week, a separate compilationrecord exists for each day.

The compilation record further specifies the expected duration of theplayback session for that day using the variable PlayMinutes. Thevariable Longterm indicates the maximum duration in which extended playmay be required. For example, a commuter who sometimes experiences longtraffic delays on Mondays and Fridays may specify that an extra hour ofextended programming should be provided for those days. Such extendedprogramming is preferably consists of non-time critical programmingwhich can be stored for future use as needed by the player.

Note that the compilation records noted above are used by the server tooptimize the content of the recommended program schedule and not toinitiate actual downloads to the player. As contemplated by theinvention, the player initiates the actual downloads by sending downloadrequests to the server. Nonetheless, the server can transmit to theclient player an indication of optimum times when downloading should berequested. In this way, the load imposed on the server can be spreadover time to avoid delays.

Program segments which are of interest to the user and which should beincluded in either the Schedule Table 307 or the Catalog Table 308 maybe automatically identified by the following mechanisms:

-   -   The subject matter codes (Interests, TopChoices and        ChoiceCounts) for a given subscriber for whom the Schedule Table        307 and Catalog Table 308 are being prepared may be compared        with the subject matter contained in the Program_Segment        record's Subject for each subject category description and each        individual program description. Note that the Program_Segment        record for a subject category description may identify related        categories. In this way, an indication that a subscriber is        interested in a particular category may be used to identify that        category, any related category, and any program which specifies        that category in its Program_Segment record. A weighting value        may be calculated to indicate the extent to which the        subscriber's stated interests match a given program or category        of programs. Programs to which high weighting values are        assigned are placed in the Schedule Table if the usage log data        does not indicate the subscriber has already played that        program, whereas the remaining programs having a weighting value        greater than a predetermined threshold are placed in the Catalog        Table 308. The duration of the programs specified in the        Schedule file 307 is governed by the scheduled session lengths,        communications throughput, and client storage capacity values        contained in the DataRate, Capacity and WeekDays fields of the        Subscriber record.    -   The attributes of the subscriber (birthdate, sex, marital        status, and household size) specified in the Subscriber record        may be matched against the corresponding descriptions contained        in the subject and program Program_Segment records (youngest,        oldest, male, female, houselow, househigh) to identify programs        and categories of programs likely to be of interest to a        subscriber having those attributes. An advertiser-supplied        function defining this relationship is specified by the        DemographicMatch function id field of the Advertiser record, as        discussed below.    -   The host server may advantageously use an optimization technique        such as linear programming to complete the segment selection        process. The optimizer will take into account the Subscriber's        time constraints, cost constraints, and subject preferences. The        time constraints used in the optimization are: the playing time        available for the current day at the player, the download time        available, the percentage of segments usually skipped by the        Subscriber. The cost constraints are Subscriber ChargeLevel and        the accumulated value of individual advertising segments. The        subject preferences are based on the user's expressly stated        interests and others interests inferred from the user's playing        selections, as noted earlier. Each segment resident in the        database at the time of download is evaluated against the        constraints and the optimizer thus chooses a set of segments        which is best for the subscriber at that time.    -   The weighting value computed for a segment in the database may        also be advantageously varied in accordance with the age of the        segment; that is, segments will decline in value as they age        with the rate of decline being depend on the Timeliness        attribute stored in the Program_Segment record. If the        subscriber misses a download for a given day, the timeliness        factor will allow the host server to compensate for the lost        listening opportunity by adding articles from prior days which        are still of interest to the Subscriber.

Targeted Advertising

In order to identify and insert advertising program segments into theSchedule Table 307, the preferred embodiment of the invention utilizesadditional information which describes each advertisement to be placedbefore subscribers. This information is placed in an Advertisementrecord having the structure defined earlier and held in theAdvertisements Table 311. The ProgramID field of the Advertisementrecord identifies a Program_Segment record (described earlier) whichdescribes the content of the advertisement itself. The remainder of theAdvertisement record contains additional information used to control themanner in which the identified advertising program segment is selectedfor insertion into the programming supplied to subscribers.

The AccountNo field of the Advertisement record identifies the entityrequesting the advertisement which is typically the same as, but notnecessarily the same as, the entity specified in the ProviderID field ofthe Program_Segment record for advertising segment. The Subjects andImportance arrays in the program segment for the advertising (specifiedby the ProgramID field) may be matched the subject matter categoriesused by or created for subscribers to indicate their interest and may beused to produce a numerical value InterestMatch indicative of the extentto which a given advertisement is likely to be suited to the interestsof a particular subscriber. The following algorithm, expressed as afunction in Pascal, returns an integer value, which may be employed toderive the InterestMatch value indicating the degree to which anyprogram segment matches the interests of a given subscriber:

function InterestMatch(SR: subscriber; PSR: program_segment): integer;var I: integer; InterestCount: integer; ChoiceCount: integer; begin InterestCount:=0;  ChoiceCount:=0;  for I:=0 to 15 do ifPSR.subjects[I] > 0 then for j:=0 to 15 do begin if SR.Interests[j] =PSR.Subjects[I] then inc(InterestCount, PSR.Importance[I]); ifSR.TopChoices[j] = PSR.Subjects[I] theninc(ChoiceCounts,(20−j)*PSR.Importance[I]); end else break;return(InterestCount + (ChoiceCounts div 10); end; { InterestMatchfunction }

The foregoing function identifies all of the Subjects codes specified bythe program_segment record for a program segment (including a segmentspecified the ProgramID value of the Advertisement record for thatadvertisement) which also match a subject matter code in which thesubscriber described by the Subscriber record SR has expressly stated aninterest, or has shown an interest base on programs actually played. Ineach case where a match was found, the Interest_Match value is increasedby an amount related to both the weight given to the category inadvertising program's Importance array and the level of interestindicated for the subscriber. Note the InterestMatch function describedabove can be used to generate a numerical indication of the degree towhich a given subscriber may have an interest in any program segment,whether that segment contains advertising, entertainment, news, or othercontent. In the case of advertising program segment however, the Subjectand Importance values are assigned by the advertiser in order to definethe interests held by target subscriber to whom the advertiser wished todirect the advertisement.

In addition to the InterestMatch value determined above, weight may begiven to the subscriber's personal characteristics using a similarweighting function specified th the function id DemographicMatch which,like interest match, returns a value based on an advertiser specifedrelationship based on the subscriber's personal characteristics (age,sex, marital status, size of household, etc.) as previously noted. Thevalue DemographicWeight may be used to specify the relative importanceof demographic values derived by the DemographicMatch function and thevalue returned by InterestMatch.

All advertisements scheduled for a given subscriber may then beprioritized based on the resulting calculated weight assigned to eachadvertisement by matching algorithms which compare the characteristicsof the subscriber with the makeup of the target audience defined by thefields of the Advertisement record. These advertisements are thenpreferably inserted into the programming Sequence with the advertisementhaving the highest weight being scheduled to occur first in thesequence, thereby insuring that the best fitting advertisements areincluded in the programming and most likely to be played by thesubscriber.

Controlling the Quantity of Advertising Delivered

The rate at which advertising is actually inserted by the player iscontrolled by the ChargeLevel value in the Subscriber record for eachsubscriber. The ChargeLevel value (a number from 0-255) indicates therate at which a subscriber is willing to accept advertisements. Anadvertisement duration count variable (not shown) maintained by theplayer 103 accumulates the total duration of actually played advertisingwhile a program duration count variable accumulates the total durationof actually played programming. An integer division of these to durationcount values indicates the proportion of time being devoted toadvertising. If this proportion falls below a threshold value determinedby the value of ChargeLevel, additional advertising is inserted betweenprogram segments until the desired proportion is again reached. In thisway, advertising skipped by a subscriber will be replaced later bydifferent advertising to yield the proper proportion of programming toadvertising, thereby achieving the subscription charge rate requested bythe user.

The Schedule 307 downloaded to the player, and the associatedprogramming, announcement and advertising segments sufficient to providea complete program sequence with adequate advertising to meet thepreference of the subscriber, creates total program content longer thanthe expected playing time indicated by the PlayMinutes variable of thedays Compilation record. As a consequence, the player builds acollection of program and advertising segments which can be played inthe future and need not be downloaded. Downloading of actual programsegments therefore preferably occurs at the request of the player whichscans the Schedule for program and advertising segments not alreadyavailable and issues a request for the needed segments using the URLscontained in the players catalog of Program_Segment records. Inaddition, as noted earlier, the subscriber has the opportunity to reviewthe local catalog for particular program segments of interest which canbe placed in the next day's schedule (and downloaded then at the requestof the player if not already resident). The catalog of available itemsis supplemented by the NewCatalog Table items downloaded from the serveras library items are identified whose makeup matches that of thesubscriber and should be included, either immediately in the daysSchedule Table, or made available by inclusion in the downloadedNewCatalog Table alone.

Accounting Functions

The preferred embodiment of the invention processes the usage log datacreated during the playback session as described in connection with FIG.3 to produce a variety of accounting and analysis reports and billingfunctions.

Each advertising, announcement and program segment played on the playercreates a UsageRecord stored as an record in the Usage Log Table havingthe following content:

UsageRecord = record Subscriber: integer; ProgramID: integer; Start:datetime; Volume: Integer; Playingspeed: Integer; end;

The Subscriber field contains the AccountNo of the subscriber which usedthe program segment, and the program segment itself is identified by theProgramID field. If the value of ProgramID is negative, the recordindicates a failed hyperlink attempt and the ProgramID is posted to theRequested Table 301 so that the formerly missing program segment willbecome a candidate for downloading to the player. In the UsageRecord,the Start field contains the starting time of day (to the nearestsecond), the Volume field contains a value indicating the level at whichthe volume was played, and the PlayingSpeed field contains a valueindicating the playing speed. A negative playing speed value may be usedto indicate that the player was placed in the “play highlights” mode sothat only highlight passages were being played.

As noted earlier, each UsageRecord is processed to modify the Subscriberrecord field TopChoices by first building an ordered list of subjectmatter categories and the corresponding counts of the number of timeseach category was played in the session described by the Usage LogTable. These counts are then used to increase the existing Choice Countsfor the subject matter codes indicated in the TopChoices array, and theTopChoices and ChoiceCounts arrays are then jointly resorted into orderby descending number of plays. To insure that subject matter categoriesrecently used are allowed entry into the list, the lowest five oldentries are discarded each time if necessary to make room for the fivemost frequently played categories in the current usage log which werenot already on the list. The TopChoices array accordingly contains anadaptively learned set of subscriber subject matter preferences which iscontinuously modified automatically without requiring attention from thesubscriber.

Subscriber billing is based on the accumulated amount of programmingactually played by the subscriber with credit being given foradvertising actually presented to the subscriber. To accomplish this, adetailed billing history can be constructed from the usage log whichindicates the programs heard, the duration of each, and the cost (orcredit) attributable to that program segment. The TimeRate valuespecified in the Program_Segment record for each item specified in theUsageRecord's ProgramID is multiplied times the segment duration(determined by subtracting the start time of the segment from the starttime of the next segment specified in the next UsageRecord). TheTimeRate is a signed integer, with negative values being indicative ofcredits (for advertising) and positive values being indicative ofcharges for programming. Note that each program segment and advertisingsegment can have a different rate, allowing the system to accommodatecharging rates that reflect different programming costs.

Such costs frequently are affected by the royalty rates charged bycontent providers as well as the extent to which costs are defrayed byadvertisers. In accordance with the invention, each UsageRecord may alsobe posted into the Content Providers Table 315 which maintains royaltypayment records for amounts due to content providers. As in the case ofsubscriber billing, the processing of UsageRecords allows the embodimentshown in FIG. 4 to provide detailed information to content providers,identifying the extent each provided program segment was actuallyperformed. Content providers can also be provided with demographicstatistics identifying the characteristics of the subscribers who choseto play the content provided, as well as an identification of the extentto which program segments were skipped while in progress, tending toidentify programs which were had continuing appeal during the sessionand those that did not.

Similarly, advertisers can obtain detailed billing records indicatingthe precise extent to which advertising was actually presented, andpaying only for advertising known to have been effectively delivered. Inaddition, demographic data can be provided to advertisers indicating themakeup of persons who played the advertising, as well as the demographiccharacteristics of those who did not, in order to better target futureadvertising.

Finally, the UsageRecords are processed to post use data into thePrograms Table, modifying the Plays and TotalTime fields of theProgram_Segment records to reflect the extent to which programmingmaterials are actually presented. This information, as well as thedemographic statistical information indicating which classes ofcustomers are listening to which classes of programming, is ofsubstantial value in collecting a library of offered programming whichbest fits the needs of the community of subscribers.

Program Format and Organization

The programs which reside in the program database 303 seen in FIG. 4 arepreferably formatted in accordance with a standard structure tofacilitate “skimming” the sequence of program segments defined by theselections file 351, and to make it possible to perform jumps todifferent predetermined locations in the program sequence.

As previously noted, the program database 303 may include, for a givenprogram segment, both a recorded audio narration and a text transcriptor, in the alternative, a text transcript alone which can be convertedinto a spoken narrative by speech synthesis. While these narratives mustbe listened to in a linear sequence, it is nonetheless possible toselectively access individual program segments by organizing the overallprogram compilation into a hierarchical structure in which:

-   -   As noted earlier, the program segments which are available in a        master library are described in a catalog and associated with        descriptors of various kinds, allowing the content of the        compilation to be tailored to the preferences of the subscriber,        both through express selections made by the subscriber and by        selections (or suggestions) made automatically by matching the        subscribers known preferences and interests against descriptors        which characterize the programs segments, as previously        described.    -   The resulting program compilation is then divided into        components each having a beginning, or entry point, to which        jumps can be made by the listener by a dynamic selection        mechanism which is operative during the listening session.    -   A given program segment (i.e., an entity described in the        program catalog and selected automatically or expressly by the        user as being of interest as previously described) is        advantageously combined with other related program segments to        form a sequence of associated segments here called a “subject,”        forming a subsection of the overall compilation. A “subject”        collection of program segments may (but need not) directly        correspond to the named subject matter categories utilized to        specify subscriber's preferences as noted earlier. A “subject”        collection begins with or is preceded in the scheduled program        sequence by a spoken announcement of the subject, giving the        user the opportunity to skip immediately to the next subject,        thereby skipping all of the program segments comprising that        subject.    -   As a consequence, by the simple expedient of skipping from        subject announcement to subject announcement, a user can locate        a particular subject of interest. For example, if a given        program compilation as defined by the Selections file (having        the format illustrated at 351 in FIG. 5) contains one hour of        programming divided into 8 different subjects collections, the        user can quickly locate a subject of interest by skipping from        subject announcement to subject announcement until a subject of        interest is announced, at which time the player is allowed to        proceed to the next level in the hierarchy, a “topic”        announcement for the first program segment in that subject        collection.    -   Each program segment begins with a “topic” announcement which        consists of a brief, summary description of the content of the        program segment to follow. Again, at this level, if the user        upon hearing the topic announcement elects to skip that program        segment, the player automatically advances to the entry point        preceding the next topic announcement. In this way, within a        given subject, the user can skip from topic to topic to select        only the program segments of interest.    -   Following the topic announcement, if the program segment        consists of narrative text, such as a news program, the        narrative is presented in a sequence of paragraphs, with the        first paragraph providing an overview summary of the content of        the program segment (topic) and the succeeding paragraphs        providing increasing levels of detail. The narrative is thus        presented in a fashion not unlike that followed in news stories        written by journalists for print publication, but with more        dependable rigor, recognizing that the listener presented with a        one-dimensional audio presentation must necessarily depend on        the consistent adherence to the subject, topic, summary        paragraph, and increasing detail sequence to substitute for the        random access provided by two-dimensional presentation of        headlined newsprint articles.    -   Finally, within paragraphs, the sentences should be carefully        organized with leading topic sentences, again giving the        listener a preview of what is coming next in the sequence to        enable that material to be skipped if it is not of interest.

By way of example, a program compilation for a given subscriber mightillustratively consist of seven subjects: world news, national news,local news, computer trade news, email and voice mail messages, countrymusic, classical music, and the listener may skip from subjectannouncement to subject announcement to readily locate the beginning ofany one of the six subjects. The four “news” subjects each consist of acollection of structured program segments, each of which begins with asubject announcement, again allowing the user to skip from subject tosubject, listening to only those which are found to be of interest.

Similarly, the music selections (“topics”) within each of the two musicsubjects, “country music” and “classical music,” are preceded with abrief announcement identifying the musical selection which follows,allowing the user to quickly skip from announcement to announcementuntil a desired selection is found. Because many listeners prefer musicwithout announcements, the subscriber may request that the announcementsbe suppressed during continuous play and/or that the beginning of eachmusical segment be played instead of identifying announcements when themusical collection is being “skimmed” to locate the next selection to beplayed. To simplify the player controls, the subscriber is preferablyselects the extent to which narrative music identification announcementsare to be played at step 211 seen in FIG. 2, at the same time the useris given the opportunity to edit the downloaded program sequence.

Play Highlights Mode

To further facilitate rapid skimming, the player may be adapted tosupport playback in what is here termed the “play highlights” mode. Justas a student often uses a marker to highlight important names andphrases in printed text, key points in the audio narrative may be taggedas highlights such that, when the user places the player in a “playhighlights” mode, the player automatically skips from highlightedpassage to highlighted passage, greatly increasing the speed ofpresentation, but allowing the user to revert to normally play modewhenever a highlighted passage attracts the users interest for moredetail.

Highlighted passages may be advantageously identified by means of asequence of relative byte locations (integer offsets from the beginningof the program segment) which form part of the selections file 351 andwhich specify the start and end of each highlighted passage. The player,when placed in the “play highlights” mode, then plays only thosepassages identified as highlighted portions of the program segment file.

Hyperlink Jumps

In addition, the structured program files may advantageously contain,where appropriate, “hyperlink” passages, which may take the form ofannounced cross references to other materials, or sentences or phraseswhich describe related information contained elsewhere in the downloadcompilation but which do not follow immediately in the sequence. Inorder to alert the listener to the fact that a sentence or passage is ahyperlink to other information which is out of the normal playbacksequence, an audible cue may advantageously proceed, accompany, orimmediately follow the passage in the normal playback which identifiesthe character of the hyperlinked material. Using the terminologytypically employed to described hypertext, the normal programmingsequence includes “anchor” passages which are identified by an audiblecue signal of some type and are further associated with a reference tohyperlinked material to which the playback may jump upon the listener'srequest. Hyperlinked material, like all other programming, isadvantageously preceded with a topic description and, if the hyperlinkedmaterial is a narrative, it should begin with a summary paragraph,followed by increasing detail.

A hyperlink may be directed to a program segment which is not present inthe current selections list. In that case, the Link variable contains anegative number to distinguish it from references to a particularSelection_Record, and is interpreted as the negative of a ProgramIDnumber. If the referenced ProgramID is available in the player's massstorage system, it may be fetched an played and, upon its conclusion, anautomatic return is made to the original sequence. If the referencedProgramID does not refer to a locally stored record, the listener isinformed that it is currently unavailable, but will be included in thenext download for the next session.

In addition to having means for accepting a user command to execute ajump to the hypertext material, the player also advantageously includesa mechanism (special key or voice command response) which, whenactivated, causes a “return” to be made to the playing sequence at thepoint of the original anchor from which the hyperlink was performed. Inthis way, a listener may listen to as much or as little of the linkedinformation as desired, retaining the ability to return to the original.Just as computer subroutines may be nested by saving the returnaddresses of a calling instruction in a stack mechanism, a hyperlink maybe executed from within a hyperlinked narrative, and so on, with thelistener retaining the ability to execute a like sequence of returns toresume the playing sequence at the point of the first hyperlink call.

To control subject and topic skipping, as well as hyperlink jumps, theselections file seen generally at 301 in FIG. 4 preferably takes theform of a sequence of records, each having the structure defined by thefollowing Pascal record definition:

type Selection_Record = record LocType: Char; Location: Integer; end;

where LocType is a single byte character having the values and meaningsshown in the following table:

LocType Meaning “S”, “s” Subject Announcement “T”, “t” TopicAnnouncement “P”, “p” Programming content segment “Q”, “q” Advertisingsegment “G”, “g” Glue(announcement) segment “H” Highlight start offset“E” Highlight end offset “A” Anchor start offset “M” Bookmarked anchorstart “B” Anchor end offset “L” Linked segment “R” Rewind to identifiedlocation “I” Image identification “J” Image display start offset “K”Image display end offset “C” Accept comment “V” Accept value designation“X” Accept list termination “Y” Accept “Yes”/“No”

As seen in the table, highlight passages are specified by twoSelection_Records, an “H” marking the beginning and an “E” recordmarking the end of the highlight passage. The Location field in eachrecord contains the byte offset from the beginning of the currentprogram segment whose identity is specified by the last preceding “P”Selection_Record which contains the ProgramlD of the program segment inwhich the highlight passage occurs. “Q” advertising segments and “G”announcements segments behave like regular programming content segments,but are uniquely identified to enable the player to skip over, or skipto, advertising and glue segments when appropriate. In the “playhighlights” mode, the player scans the selections file and plays theprogram segments for each subject and topic announcements but plays onlythose portions of an identified program segment which are specified ashighlight passages or as anchor passages for hyperlinks.

It is desirable to further provide a mechanism for subdividing narrativeprogramming segments into subparts (e.g. paragraphs). Lowercase LocTypevalues “s”, “t”, “p”, “q” and “g” are used to subdivide subjects,topics, programming, advertising and glue segments respectively. Thelowercase Loctype records provide the markers needed to implementsubdivision skipping, as previously discussed, to enable forward andbackward navigation within longer program segments, and further providespassage identifiers which may be used to better synchronize the audioand visual transcript presentation of longer passages.

An “I” Selection_Record contains an integer identification of an imagefile which is downloaded and stored using a filename found in an imagefilename table indexed by the image identification number. This indirectaccess to the image files eliminates the necessity of storing thefilenames themselves in the selections file 351. The “I” image fileidentification records immediately precede a “J” record which specifiesthe offset location from the start of the compressed audio file wherethe image display begins. In normal “slide show” presentations, thecurrent image display continues until the position indicated by asubsequent “I”-“J” record at which point the display shifts to thesecond image. The “K” record type is provided to indicate the positionat which the current image display is turned off for those instanceswhen it is desired to suppress the image display entirely.

Each anchor passage for a hyperlink is specified by three selectionrecords: an “A” record indicating the start of the anchor passage, an“B” record indicating the end of the anchor passage, and a “L” recordcontaining the offset location within the selection file to which a jumpis made if the user requests a jump to the hyperlinked material.

As discussed in more detail later in connection with FIG. 7 of thedrawings, the position and identification of highlighted passages,hypertext links and synchronized images may be conveniently expressedusing conventional hypertext markup language to tag the text of thenarrative to being presented in the interactive multimedia formatcontemplated by this aspect of the invention.

The start of bookmarked passages are identified with a special anchordesignation, “M,” followed by a “B” record to identify the end of thebookmarked passage. If a voice annotation is added, the player places itin its own program segment which is identified with a negative ProgramIDin the following “L” record. The presence of the annotation may then bemade known to the listener during subsequent playback of the markedpassage by means of a distinctive audible cue, and the annotation maythen be listened to in the same fashion as any other out of sequencelinked material. Note that bookmarked passages and annotations are notedboth in the usage log file, as discussed earlier in connection with FIG.3 at 280 and 281, but also their presence is also recorded in theSelections file 351 by inserting “M”, “B”, and (if annotations exist)“L” records, making it possible to immediately replay annotations orreturn to replay bookmarked passages.

Annotations differ from “comments.” Like an annotation, a comment isalso stored in its own program segment, but a comment operates as apublic or private message generated by the user and communicatedpublicly or privately to (1) a designated special interest group, (2)the originator of a program segment, which may be the author of earliercomment, (3) the system host, or (4) the person producing the comment toform a note for future reference. While both comments and annotationsmay be created at the request of the user at any point during a playingprogram segment using the “Accept” command (see 263-264 in FIG. 3), theuser may be prompted by a pre-recorded request for a comment, or otheruser input, with the prompting request being placed at any point in aplaying program segment, typically after an audio prompt which explainsthe nature of the information being requested.

Requests for information from the user preferably take one of threeforms which are implemented by the records in the schedule fileidentified by the LocType codes “C”, “V”, “X” and

A “C” record causes the player to temporarily pause the playback andrecord a voice response from the user which may be arbitrarily long andwhich is uploaded to the server 101 to form a new program segment in themanner to be described under the heading “Comment Handling.

A “Y” record pauses the playback and awaits a “Yes” or “No” responsefrom the user which is then recorded in the usage log. The yes/noresponse request allows a program provider to obtain response data fromsubscribers.

When simple “yes”/“no” answers are inadequate, a series of “V” recordsmay be used to identify a set of prompt values from which the user mayselect, with the end of the list being indicated by a “X” record. Thenarrative of a program segment might, for example, proceed as follows:“We would like to know which of the following four ice cream flavors isyour favorite. Say the word “YES” promptly when your favorite ismentioned. V chocolate V vanilla V pistachio V peach E″. In the example,the V characters indicate the position of the start of each promptedchoice and the E character indicates the end. If no affirmative voiceresponse has been accepted by the time in the playback the positionindicated by the E selection record, the player returns to the positionsindicated by first of the series of V records to repeat the choices.When a valid response is received, a response value is written into theusage log indicating the ordinal position of the selected response.Given the prompts above, for example, if the user says “YES” after the“chocolate” prompt, the response value 1 is written to the usage log, ifthe user selects ‘vanilla’ a 2 is written, and so on.

The Selections File

FIG. 5 shows an illustrative sequence of Selection_Records making up aselection file indicated generally at 351 which illustrates the mannerin which the user may navigate the playback session between playbackpositions designated by the selection file. At any given moment, thenext item of programming to be played is specified by an integerregister CurrentPlay seen at 353 which holds the record number of theparticular Selection_Record in the selections file 351 to be playednext. As shown, CurrentPlay points to a subject Selection_Recordidentified by the LocType “S” 355 and a Location field 357 whichcontains the ProgramID of an announcement program segment whichdescribes the subject. If the user issues a skip command during orshortly after the time when subject announcement is played, the playerexecutes a skip to the next subject, which is accomplished by scanningthe selection file 351 until the next subject Selection_Record seen at360 is located, and then performing a jump by inserting the location ofSelection_Record 360 into the CurrentPlay register 353, causing theintervening material to be skipped as indicated by the dashed line 362.

If, instead, no subject skip is requested, the CurrentPlay register isincremented by one when the subject announcement concludes, causing the“T” Selection_Record 364 to be used to fetch and play the topicannouncement specified by the ProgramID in the Location field of record364. If a skip is requested during or shortly after the time when topicannouncement specified by record 364 is played, the player scans theselection file 355 until the next “S” or “T” Selection_Record is foundat 366, causing the intervening program material to be skipped and thetopic announcement specified by record 366 to be played next. If, asillustrated by the Selection_Record 366, there are no more topics withina particular subject when a topic skip is requested, the player skipsthe remainder of the last program subject within the current subjectcollection and plays the next “S” subject announcement. Thus, topicskips take the user quickly to a subject announcement, from whichsubject skips may be executed until a desired subject is reached. Inthis way, a desired program segment, no matter where it is located withrespect to the current selection, can be readily found.

If the user issues a skip command during the body of a programselection; that is, when neither a subject or a topic announcement isbeing played, the player advances to the next “S” subject or “T” topicrecord, skipping the remainder of the program selection. Thus, the usercan quickly resume skimming on the subject and topic level at any time.

The user may also issue a “Back” command at any time. Back commands worklike Skip commands at the subdivision, subject and topic level. If aBack command is issued when a subject is being played, the player scansbackward to the previous subject announcement, which is then played. Ifthe user issues a back command when a topic announcement is beingplayed, the player scans backward to find the previous subject or topicannouncement, which is then played. If the player issues a Back commandduring the playing of a programming segment, the player returns to thebeginning of the prior subdivision (if any) or the prior topicannouncement for the current program segment, thus enabling the user toeasily “replay” a current segment from the beginning if desired. As inthe case of forward skip commands (SKIP TOPIC and a SKIP SUBJECT), BACKTOPIC and BACK SUBJECT commands can be made available to the user suchthat backward navigation from subdivision to subdivision occurs usingBACK TOPIC whereas the issuance of a BACK SUBJECT command always returnsthe playback point to the beginning of the prior subject matterdescription.

The manner in which a “Back” command is handled as described above issubject on additional variation: The position at which each skip forwardcommand is issued may be advantageously saved so that, upon the issuanceof a subsequent Back command, the user may return to the position atwhich the skip forward position was issued. This allows the user, forexample, to skip forward to listen to the nest program announcement, andthen use the Back command to return to the point from which the skipforward command was issued. These position indications may be saved asmarkers in a bi-directional list, allowing the user to skip forward orbackward to any position from which a prior jump was made.

When the player is first activated, CurrentPlay is set to 1 to beginplay with the first topic announcement specified by the ProgramID 357.The end of the selections file 351 is marked with an “R”Selection_Record 380 which contains the location value 1. When theplayer encounters this record, it resets the CurrentPlay register to 1,and the playing sequence begins again. This arrangement creates, ineffect, an endless loop, allowing the user to skip forward in circularfashion through the entire program selection to locate desiredprogramming, regardless of where the CurrentPlay register is set. Whenthe player is given a further back command after the beginning of thefile is reached, the backward scanning process finds the record 382,another “R” rewind record which contains the location of the last “S”subject Selection_Record. In this way, the selection file 351 behaves asa bi-directional endless loop.

Hyperlinks are implemented by means of anchor passage identifiers, the“A” and “B” Selection records which respectively identify the anchorpassage, and a “L” link identifier which holds the location of asubject, topic or highlight Selection_Record. The “A” and “B” selectionrecords enable the player to add an audio cue (such as a tone, low-levelchime, or the like) to the beginning, end, or during any passage in anyprogram selection. Whenever the user issues a “Go” command (seen at 265in FIG. 3), the player will execute a hyperlink jump to the locationindicated by the last “L” record in the selection file. When the jump ismade, the location in the “L” record is inserted into the CurrentPlayregister 353 after the previous contents of the CurrentPlay register aresaved in (pushed into) a zero-based stack 390 at the stack cell locationspecified by the contents of a StackPtr register 392, which is thenincremented. Whenever the listener issues a “Return” command, thepreviously pushed selection file record location is popped from thestack 390 and returned to the CurrentPlay register 353, and the StackPtrregister 392 is decremented. A “Return” command issued whenStackPtr=zero (indicating an empty stack) produces no effect.

The hyperlink capability described above may be used to implement aprogram menu of the type described earlier in connection with FIG. 3. Amenu program segment may be included in the program compilation whichincludes a series of spoken descriptions of subjects or topics, eachdescription being the anchor portion of a hyperlink to the correspondingsubject or topic.

Although hyperlinks to subjects and topics are typical, it should benoted that the arrangement shown in FIG. 5 can be used to link anypassage to the beginning or end of any highlighted passage or to thebeginning or end of any anchor passage simply by placing the selectionfile location of that target in the “L” link Selection_Record formingthat link.

In its preferred form, the individual program segments are stored in arandom access mass storage system permitting program segments to bephysically stored in an order unrelated to the actual dynamic sequencein which those segments are played. Forward and backward skimming,highlight playing, and hypertext jumps can accordingly be implementedwithout any noticeable delay being apparent to the user, unlike thedelays which are experienced in forward and rewind operations on aphysical tape player, or even the briefer delays experienced uponselecting a different track of a compact disk music album.

As contemplated by the invention, the integration of structured audioannouncements and content, as will as cross-referencing and indexinginformation in the audio program compilation, allows the player to bemuch more interactive than a simple tape recorder. The user has theability to browse and skip through the audio program in a very activeway, without any requirement to look at a visible display of the programcontent. The ability to navigate the program using only audio promptsand/or small number of buttons for a user interface make the playbacksystem which utilizes these features of the invention particularlyattractive for use by automobile drivers, who can select their programcontent much more effectively and with less drive distraction thancurrently possible with a conventional automobile radio, tape or CDplayer.

Program Production

FIG. 6 shows the method followed to produce program content which isstructured in accordance with the invention to facilitate interactiveprogram selection. The first step in program production is to build astructured database of ‘articles’ which are candidates for inclusion inindividual subscriber compilations.

The authoring system seen in FIG. 6 scans a wide range of data sources401 for potential content as indicated at 403. Examples of data sourcesmight be news service wire feeds or newsgroups on the Internet. Theauthoring system subdivides the accessed program data into programsegments (topics) and indexes each segment by subject area at 405. Inthe case of text data, this indexing may be done automatically byparsing the text into words and building a conventional inverted fileword index to the program segments. In the case of audio programming, atext transcript may be prepared using conventional speech recognitionmechanisms to for a transcript, and the transcript may then be indexedby the terms used. Alternatively, human indexers may produce descriptivewords and phrases to characterize the content of a program segment, andthese descriptors may be used to index those segments.

After the indexing has been performed at 405, the authoring system thencompares the each program segment's index data at 407 with system wideselection criteria in a system database 409 to provide a “SystemFilter.” The system filtering function identifies those programs whichof potential relevance to one or more of the established subject mattercategories offered to subscribers. Accordingly, the system filterdatabase 409 may take the form of a set of words (descriptors) of knownrelevance associated with each of the subject matter categories in thecatalog. The comparison function at 407 scans the words in eachcandidate program segments to form a weighting value indicating thefrequency (density) of the occurrence of descriptors for each category.Program segments whose content produces a high weighting value withrespect to any category are automatically associated with that categoryand retained for further processing as indicated at 408, while programsegments producing no weighting values greater than a predeterminedminimum may be completely discarded at this stage, as indicated at 411,since their content does not indicate a sufficient likelihood of beingof interest to a sufficient number of subscribers. Marginal programsegments may be returned to the source library 401 for possible lateruse in the event that user preferences change.

Each article which passes the system filter at 408 is processed as shownat 414 in FIG. 6. As noted earlier, and as indicated at 421, theauthoring system next prepares either a transcript for those segmentswhich consist, in their original form, of voice narration. This step maybe automated using speech recognition or manually by keyboarding tocreate the needed transcripts.

As indicated at 425, when the original material consisted of informationin text form, a human reviewer verifies that the program content is infact relevant to the subject matter categories identified by theautomated system filter processing as noted earlier, and adds additionalsubject matter categories that may have been overlooked by the automatedprocess. As a result of this automated and human-verified classificationprocess, each program segment is associated with one or more subjectmatter categories which are encoded into a standard form in the Subjectsarray of the Program_Segment record described earlier in connection withFIG. 4. These subject codes are further assigned an importance value inthe Importance array (which is parallel to the Subjects array) by thehuman author. Note that the order in which subjects codes are placed inthe Subjects array may be used to indicate the relative relevance of thesubjects to the program segment; that is, the most relevant subject isidentified in Subjects[0], the next most relevant subject is identifiedin Subjects[1], and so on. Each program is typically placed in theoutput sequence in accordance with the code at Subject[0], the subjectto which the program segment is most relevant.

In addition, the human review may compose a narrative cross referencingdescription of some or all of the program segments which weresecondarily relevant to a given category; that is, program segmentswhich were most relevant to another category but also relevant to thegiven category. This cross-referencing description may advantageouslyutilize the hyperlink capability discussed earlier such that, when theuser is listening to the description of any related program segment,that related segment may be listened to simply by issuing a Go commandto jump to the linked article, and later issuing a Return command toresume the playback at the original.point.

The body of the program segment is then organized by the human reviewerat steps 431, 433, and 435 seen in FIG. 6 to create an output programsegment having the desired structure consisting of:

-   -   a topic statement which is packaged in a separate program        segment,    -   a leading summary paragraph,    -   further content organized into paragraphs of increasing levels        of detail, in which all unnecessary detail is excluded (that is,        longer topics are digested into shorter, overview topics, with        the full version being made available in an alternative,        unabridged form which is also made available to the listener),    -   adding highlight identification to key terms and phrases, and    -   adding cross-referencing hyperlinks, with added explanatory        anchor text if necessary.

When the original program segment is a news article or the like whichwas made available in text form, the foregoing operations may be mostconveniently performed on the text, with the conversion to audio beingperformed by a human announcer or by speech synthesis after the edited,formatted and tagged text is produced. Thus, as shown at 436, the humanreviewer may compose a new article which has condensed content at 431,add a topic (title) and summary paragraph previously created at 433, andthen, at 435, add highlighting and hyperlink tags (which take the formof imbedded flags of the type used in Hypertext Markup Language “HTML”as described later in connection with FIG. 7) In order to assist thelistener in deciding whether to listen to, or skip, a given subject, itis desirable that the topic and subject announcements include astatement of the playing time, particularly for longer program segments.In addition, the playing time is recorded in the Program_Segment recordfor that segment in the field named “Duration” as noted earlier. A humanannouncer then reads the structured text, or it is alternativelyconverted into an audio program segment by speech synthesis, asindicated at 435.

If desired, the user may request the player to periodically issue a timeof day announcement. The user may set a playback preference valueindicating a desired time duration between time of day announcements.Each time such an announcement is issued, the last announcement time isrecorded. Each time a logical break occurs between program segments, thelast announcement time is subtracted from the current time and, if theresult exceeds the desired announcement spacing, a new time of dayannouncement is issued.

In addition, at the user's option, the player may also periodicallyannounce the duration of the unplayed portion of the session, enablingthe listener to skip certain programs in order to play others when theactual listening time available is less than the time available to playthe entire remaining program.

The player may be programmed to issue timed messages to the listener.For example, a program session may interrupted to remind the listener toperform some function at a particular time, such as listening to ascheduled radio broadcast. Alternatively, the player may be programmedto play identified segments at a particular time of day, or at aparticular time relative to beginning of the session (for example,fifteen minutes after the session begins regardless of what has beenplayed before or where the player is in the sequence). These programmedinterruptions are preferably performed as automatic hyperlink, enablingthe user to return to the regularly scheduled but interruptedprogramming simply be issuing a “return” command.

It should be noted that program segments may omit the “original” audiofile entirely. Instead, the audio may be generated on the user's playerusing speech synthesis, with tag to speech conversion of the taggedhighlighted materials including an audible cue. The text-to-speechtechnology might be especially useful for specialized subject areas,such as weather reports, sports scores, or stock market quotes, or otherprimarily informational articles where the content is significantly moreimportant than the form of speech.

The availability of a collateral text file makes it possible to performscanning operations to “find” particular words and phrases in thepresentation, and perform a jump to that position in the file. Thus, theuser may request the player to locate and play the next programselection in the sequence to contain the word “patent” and the player,in response to that request, performs a serial search through thetranscript text associated with each program segment until the requestedword is found, an a jump then executed to resume play at that location.

Using conventional text indexing techniques, the transcript files of theprograms specified on the current program schedule, as well as thetranscript files of other locally stored programming, may accessed bymeans of an inverted file in which each significant word in the playablelibrary is associated with the an indexing record for each occurrence ofthat word, the record containing program segment identifier for theprogram segment including the word and the offset(s) within that segmentwhere the word occurs. The availability of that inverted file allows theplayer to immediately inform the user of the number of time the termoccurs to avoid fruitless searches as well as searches which find toomuch, without actually scanning the transcripts. The availability of theprogram identifier permits the player to play for the user anannouncement of categories and topics along with a recitation of thenumber of word occurrences within that topic; for example, “The term‘cellular’ occurs 7 times in [program segment announcement], 3 times in. . . ”.

Alternatively, when a program segment contains a condensation of anoriginal, longer text article, the full transcript may be additionallymade available by downloading it to the player where it can be listenedto, by placing a hyperlink to the full version in condensed version, orprinted for further review by the listener. If desired, this capabilitymay alternatively be realized by placing the full version in a separateprogram segment, thus allowing the subscriber to select either thecondensed or full version from the catalog, or to activate a hyperlinkcall to the full version if additional detail is desired after listeningto the full version.

To encourage consistency, the reviewer/editor may adhere to the formatset forth in article templates which describe the form different classesof programs should adhere to. For example, a template might say that agiven audio article consist of a time announcement, an summaryintroduction including the article headline, and the body of thearticle. Templates may be expressed in a formal grammar which describethe desired program content in a consistent way. In addition, thetemplates may take the form of pre-written HTML forms where the programtopic description is placed in the title and the program segment commentplaced in the body portion of the HTML document, which may include tagsto identify highlighted passages and hyperlinks as explained below inconnection with FIG. 7.

The invention further supports the construction of serialized groups ofprogram segments in which the sequential episode segments may bedownloaded at one time or separately when necessary to conserve space orto handle sequential presentations which evolve in real time. Usinghyperlinks, the listener may be given the option to continue listeningat the next episode of the serial sequence, or to instead allow theplayer to continue with the next regularly scheduled program segmentidentified in the selections file, with the next episode being deferreduntil a later session.

In a similar fashion, complex subjects, such as “books on tape” andinstructional materials formed by a sequence of lessons may be readilyhandled by the invention. The subject/topic hierarchy allows suchmaterials to be presented in the catalog in outline form so that thesubscriber can choose all or part of the presentation. The organizationof such longer presentations into the structured form contemplated bythe invention makes it easy for the listener to locate and replaysegments of interest, and the highlight play mode facilitates the rapidreview of longer presentations by focusing only the central pointspresented while allowing more detail to be readily accessed if desired.

When a given program segment contains recorded original audio, such thenewly recorded narration of a human reader or an audio recording of abroadcast radio program, the file of selection records to be associatedwith that audio recording file is created by a human editor who utilizessuitable audio monitoring and editing equipment to listen to theplayback of the audio playback file and identify the byte locationwithin that audio file where highlight and anchor passages as well asresponse prompts which seek user input begin and end. In addition, forhyperlink selection records, the human editor supplies theidentification of the cross-referenced material by specifying thesymbolic name of another selection record associated with the same or adifferent program segment to which control is to be passed if thehyperlink is executed by the user. A crucial step in the production ofeach segment is the association of byte locations in the audio streamwith the records in the selection file. This association may be done bya human technician or by automatic methods.

A technician would use a computer with suitable audio playbackcapabilities and software to play the audio stream and to simultaneouslydisplay the transcript if it is available. The software which plays theaudio generates a new record in the segment file which contains thecurrent byte location within an audio file whenever the human editorpressed a key. The significance of a byte location may be indicated bypressing a selected one of a plurality of keys. For example, thetechnician could generate Subject and Topic records with the correctbyte offset simply by pressing the “S” or “T” keys at the right momentwhile listening to the audio program. The software could automaticallygenerate the synchronizing segment record and prompt the technician toassociate byte location thus identified with a corresponding location inthe displayed transcript using a mouse or other positionalidentification means. When no transcript is available, the operator maybe prompted to enter a topic or subject description via the keyboard.

The process of associating of audio location with segment recordsprocess could be automated by adding additional software to thetechnicians editing computer. For example, as indicated at 437, speechrecognition technology may be employed to automatically identify whenthe live speaker changed in an audio stream. The monitoring program thusautomatically generates a new record and prompt the technician toassociate the record with data in the transcript. Besides speakerchanges, the software may advantageously detect laughter, musicalinterludes, or laughter and use these to automatically generate segmentrecords.

The completed program segment is assembled at 438, compressed at 440,and placed in the program library as indicated at 442 where it isavailable for downloading to subscribers. The program segment (topic)thus preferably consists of (a) a compressed audio program segment file,(b) a text transcript file of characters, which is preferably in HTMLformat or in a word processing format such as the Rich Text Format “RTF”readable by most word processing software, (c) possibly one or moreimage files for visual presentation with the audio content, (d) a fileof Selection Records for the program segment which identify the subjectprogram segment announcement, the topic program segment announcement,and the program content program segment (“S”, “T”, “P”, “Q,” and “G”Selection_Records), as well as the highlighting and hypertext passagesand collateral synchronized image files tagged within the body of theprograms segment, and finally (e) a Program_Segment record for thesegment which identifies all of its component parts and which is placedin the relational Programs Table 303 seen in FIG. 4. As explained below,the use of HTML to express narrative text facilitates the compilation ofthese constituent parts of a program segment.

It should be noted that the file of Selection Records which forms partof the program segment data assembled at 438 may containcross-referencing links and these links in turn contain locationreferences to cross-referenced program segments or particular passageswithin other program segments. While a referenced program segment can beidentified by the its Program_ID integer, the byte location of aparticular passage within that referenced segment is not establisheduntil the editing noted above is completed. Consequently, symbolic namesare preferably used to initially identify all highlight or anchor textpassages, making it possible to use these symbolic names as relocatableaddresses, just as symbolic names are used to identify addresses incomputer source language which is first compiled and then linked totranslate symbolic names into real addresses at run time. In this way,symbolic names used to identify cross-referenced passages may betranslated into numerical selection file offset values loaded into theLocation field in “L” Selection_Records. As discussed previously, theseoffset values are either positive values specifying the location withinthe Selections file of the Selection_Records which identifies the linktarget, or negative Program_ID values which identify program segmentsnot specified by the current Selections file as being part of thecurrent program session content.

Comment Handling

As previously discussed in connection with FIGS. 3 and 5, the apparatuscontemplated by the invention advantageously includes means foraccepting comments, yes/no responses, and value selections from a userduring a playback session. As discussed in more detail below under theheading “Defining Audio Programming with HTML,” these prompted userinput responses are analogous to and can be composed using the <INPUT>tag form elements defined for use in standard hypertext markup language,where the “C” records in the selection file are analogous to <INPUTTYPE=“text”> HTML tags, the “Y” selection file records are analogous to<INPUT TYPE=“checkbox”> tags, the “V” records are analogous to <INPUTTYPE=“radio”> radio button tags. Together these prompt mechanism providea robust mechanism for prompting the user for and collecting responsesof various kinds

This mechanism for obtaining prompted responses may be advantageouslyemployed to request information from subscribers. For example, promptedrequests may be used to obtain program ratings from at least thosesubscribers who are willing to participate in the program ratingprocess. Using “V” and “E” records, for example, a user may be asked tograde programs by various criteria and the resulting data may then beused alone or in conjunction with other values to produce a figure ofmerit for programming, whereby programs receiving higher ratings can beassigned a higher priority. In a similar fashion, willing subscribersmay be offered the opportunity to volunteer to participate in surveys ofvarious kinds, with the added advantage that personal and preferencedata already available for each of the participants may be combined withthe survey responses is useful ways. For example, the tendency to give anegative responses on a particular topic may be correlated with the age,sex, geographic location, etc. of the respondents. Subscribers who areparticipate in the surveys may be rewarded by providing reducedsubscription rates, free programs, or cash payments.

As discussed previously in connection with FIGS. 3 and 263-264, theembodiment which described also includes the capability of acceptingcomments from a subscriber at any time during the course of programplayback. When such a comment is recorded, it is saved as separate file(or other identifiable data) together with the Program_ID of the programcommented upon, the byte location within the playing program file wherethe comment or annotation is being made, a Class variable indicating thenature of the record, the Class variable being used as the Classvariable in the Program_Segment record for the comment or annotation orcomment, and the date and time of day when the comment is being created.When the comment is created, the user is then requested to specify,either by voice response or by a keyboard selection, whether theinformation to be recorded is to be treated as:

An annotation to be appended to the playing program record; or

A comment which is treated as an independent message/program segment.

The user further indicates the extent to which such an annotation orcomment is to be made available to others. If designated as beingpublic, annotations become available to any other subscriber whosubsequently plays the program, at least to the extent that a givensubscriber indicates that the playback of annotations is desired.Private annotations are simply stored in the user's local disk storageare (at 107 in FIG. 1) for future reference whereas public annotationsare uploaded to the server where they are saved as separate files keyedto the original by means of the downloaded selections file for thosesubscribers who desire to hear annotations.

Comments are designated as being public or private messages. Publiccomments become independently available to all subscribers who haveindicated an interest in the subject matter category(s) to which thecomment relates. By default, a comment is assumed to relate to the samecategories assigned to the program segment which was playing when thecomment was produced, but these category codes may be changed by theuser during the editing session (seen at 217 in FIG. 2). In addition toaltering the subject matter codes for comments already dictated, theediting capabilities made available to the user at step 217 mayadvantageously include the ability to delete dictated comments so thatthey are not uploaded at all, direct comments to specific subscribers oremail addresses, and enter new comments on any designated programsegment in the current catalog by dictation or keyboarding.

In order to provide an appropriate program description for longertopics, whenever a user records a comment have a duration which exceedsa predetermined elapsed time, the player 103 performing the recording(at 264 in FIG. 3) produces an audio announcement requesting that theuser dictate a brief summary of the comment which is used to form thetopic description for the longer program segment. In the catalog listingprovided to subscribers who desire access to comments as well asprograms in a particular subject matter area, comments are listed inoutline form as items which are subordinate to the parent program orcomment to which they relate. The Commenton field found in theProgram_Segment record for each comment provides the information neededto display the hierarchical tree. The public comment mechanismcontemplated by this aspect of the invention provides a useful facilitywhich enables subscribers to exchange information with each other inspecial interest groups which function much like the UseNet groups onthe Internet, but with a conversational ease and informality that audiorecording makes possible.

A subscriber can elect the degree to which public comments orannotations are to played back along with programs or topics ofspecified interest. Comments or annotations can be excluded entirely, alink may be imbedded which may be executed at user request to play thecomment or annotation at the point in the file where the comment orannotation was played, or all comments and annotations may be playedimmediately without first requesting user approval.

Private comments are not posted to the subject matter categories and aremade available only to (1) the author of [specified by the Provider_IDof] the program segment being commented upon; (2) the host system, or ahost system editor responsible for the subject matter area about whichthe comment is concerned; or (3) some other destination specified by theuser. By sending comments to the author, the user can make a direct butprivate response to anything contained in a message or program createdby that author. Particular advertisers or other content providers mayencourage such comments and offer subscriber credits or other incentivesto those who are willing to make comments.

The ability to send comments to the responsible host editor provides adirect mechanism by which a subscriber may express satisfaction ordissatisfaction about the programming content provided, suggest otherprogramming which would be of interest, and the like. Moreover, theto-host comment provides a mechanism to assist the editors to identifysubscribers who may be inappropriately injecting offensive material tothe annoyance of other subscribers. In addition, questions about theoperation of the system may be directed to the host, thereby providinghelp and customer support to subscribers who may need assistance.Finally, the host may provide additional services (fact finding,transaction processing, and the like) which are made available on a feebasis to interested subscribers.

Finally, the ability to direct comments to specific people allows thesystem to provide voice-mail like functions among subscribers. Usingspeech recognition, dictated comments may be translated into textmessages that could be sent to anyone having an E-mail address orfacsimile receiver. Alternatively, the comment could be transmitted asan audio file attachment to an E-mail message (e.g. as a RealAudiofile). In addition, like private annotations, the comment may simply beplaced on the user's local disk for future reference.

Comments and annotations are preferably stored on the player's localmass storage unit with header information designating a CommentON field(the Program_ID of the program segment commented on), the byte locationin the playing program file where the comment was dictated, the Classfield specifying the nature of the comment, and the Created date andtime stamp. The files containing public and private annotations andcomments (other than those designated for the sole use of the subscriberwhich remain on the local storage unit) are uploaded to the host at thesame time the usage log is transferred (see 219, FIG. 2).

Defining Audio Programing with HTML

Narrative text to be presented in the interactive, multimedia formatmade possible by the present invention may be advantageously expressedin the first instance using essentially conventional hypertext markuplanguage, “HTML”. FIG. 7 shows an example of the content of a portion ofan illustrative HTML text file indicated generally at 450 used to createan audio file seen at 460 and a selections file indicated at 470.

The HTML file illustrated at 450 uses conventional <IMG> tags toidentify image files, conventional emphasizing tag pairs <EM> and </EM>to designate highlighted passages, and conventional <A> and </A> HTMLtag pairs to designate the anchor text and link target of a hypertextlink. Utilizing conventional HTML to describe the narrative content tobe presented in audio form provides several significant advantages, notthe least of which are:

-   -   conventional HTML composition software may be used to add the        image and emphasis tags by means of visual tools which eliminate        the need for hand-coding on a character level;    -   a narrative text version of the audio programming may be viewed        and printed, including both the emphasized text and the imbedded        images, using most popular web browsers;    -   existing HTML files may be readily converted into audio        multimedia presentations with little or no HTML editing being        required;    -   HTML file may be made available from a server in a form which        can be viewed in the normal way by any web browser yet and        alternatively presented accordance with the invention in the        form of an interactively browsable audio program with        synchronized images;    -   the HTML file may be supplied along with the audio file as a        transcript for the audio presentation, and to permit the audio        presentation to be indexed and searched; and    -   the HTML may be automatically converted into the combination of        an audio file using conventional speech synthesis techniques to        process the narrative text with the HTML tags being used to        compile a selections file which enables the player to        interactively browse the audio file using highlighted and linked        passages, and to synchronize the image presentation with the        audio file.

As seen in FIG. 7, the HTML text passage seen at 450 begins with animage tag, <IMG SRC=“IMGFILE1JPG”>, which to specify that the display ofJPEG image in the file named “IMGFILE1.JPG” should begin at that point.The image tag is translated into a pair of “I” and “J” selection recordsseen at 472 which respectively contain the ImageID specifyingIMGFILE1.JPG and the IMGSTART byte location in the audio file 460 wherethe display of that image is to begin. This display continues until thenext <IMG> tag is encountered specifying the IMGFILE2.JPG image whichcreates the “I” and “J” selection record pair at 473. The <IMGOFF> isnot standard HTML and hence would be ignored by conventional webbrowsers, but is inserted for recognition by the selections filecompiler which responds by inserting the “K” record at 474 whichspecifies the point at which the current image display should end.

Immediately thereafter, the phrase “Television and motion pictures” isidentified as a highlighted passage by the tag pair <EM> and </EM> seenin the text 450. These tags are translated into the “H” and “E” recordpairs at 475 in the selections file 470 which identify the beginning andending of the phrase in the audio file. As discussed earlier inconjunction with FIG. 5, the highlight markers in the selections fileenable the player to play only the highlighted passages when in thehighlight mode. A second “H” and “E” record pair seen at 476 is producedby the HTML text “<EM>bandwidth</EM>”.

A conventional HTML hypertext anchor “<A HREF=‘target’>full motionvideo</A>” is processed to produce the three records “A”, “B” and “L” at478 in the selections file which respectively designate the beginningand ending of the anchor text passage and the location of a linkedinformation. The “HREF=‘target’” portion of the HTML specifies thetarget location in conventional HTML and that symbolic address is thentranslated by the selections file compiler into the location within theselections file of the selections file record which refers to thattarget or, for targets in program segments which are not part of thecurrently scheduled programming defined by the selections file, by anegative number representing the negative of the ProgramID number of thetarget program segment.

The HTML forms mechanism may also be used to incorporate requests foruser input at predetermined times during the playback of programsegments. As described earlier in connection with FIG. 5, user inputsmay take the form of recorded comments and annotations which areanalogous to the <INPUT TYPE=“text”> and the <TEXTAREA> tagged requestsin an HTML form which similarly request the recipient to supply textdata. In addition, the embodiment of the invention which has beendescribed incorporates a mechanism for accepting “YES”/“NO” selectionsfrom a user which is analogous the HTML form <INPUT TYPE=“checkbox”>tag. Similarly, the value choice mechanism using “V” selection recordsprovides a radio-button-style mechanism for indicating a user's choicefrom among several options.

Standard HTML input tags include a Name attribute which can be used asan identifier for the data entered. As HTML is translated into anequivalent audio file, the tags in the written HTML are translated intorecords in the selections file which contain byte location valuesspecifying when the player should pause the playback and accept the userresponse. The resulting uploaded usage log file (containing responses toradio and checkbox input tags) contains the response value together withthe original byte location value from the selections file which servesthe tag identifier. In order to facilitate processing of the responses,the HTML to audio conversion process may advantageously save a tablecorrelating the Name values in the HTML source with the byte locationvalues. In this way, the input tag Name parameter may be used as asymbolic identifier to identify and process response data.

The HTML input tag Value parameter is conventionally used to supply adefault response value to be supplied when the user does not supply adifferent response. Value parameters may accordingly be saved for lateruse and inserted as output data when the user does not respond to therequest for input (as indicated by the absence in the uploaded files ofany response data containing the byte location value for the tag notresponded to). In the same way, hidden HTML tags may be imbedded in theoriginal HTML and saved during the HTML to audio conversion to indicatethe correspondence between particular byte locations in the audio fileand symbolic location names identified by the symbolic Name parameterspecified in the hidden tag. Such hidden tags may be used, for example,to identify the beginning and end of particular passages and may becompared with the usage logs to determine the extent to which usersexercised their option to skip the remainder of a program during thedesignated passage.

CONCLUSION

It is to be understood that the embodiment of the invention which hasbeen described is merely illustrative of one application of theprinciples of the invention. Numerous modifications may be made to thespecific structures and functions used in that embodiment withoutdeparting from the true spirit and scope of the invention.

What is claimed is:
 1. Apparatus for disseminating a series of episodesrepresented by media files via the Internet as said episodes becomeavailable, said apparatus comprising: one or more data storage servers,one or more communication interfaces connected to the Internet forreceiving requests received from remotely located client devices, andfor responding to each given one of said requests by downloading a datafile identified by a URL specified by said given one of said requests tothe requesting client device, one or more processors coupled to said oneor more data storage servers and to said one or more communicationsinterfaces for: storing one or more media files representing eachepisode as said one or more media files become available, each of saidone or more media files including a compressed audio recording and eachbeing stored at a storage location specified by a unique episode URL;storing attribute data describing currently available episodes in saidseries of episodes in said one or more data storage servers, saidattribute data describing each given one of said currently availableepisodes including: (a) displayable text describing said given one ofsaid currently available episodes, (b) an identification of the seriesof episodes to which said given one of said available episodes belongs,and (c) one or more episode URLs specifying the storage locations of oneor more corresponding media files representing said given one of saidepisodes; from time to time, as new episodes in said series of episodesbecome available, processing said attribute data in said one or moredata storage server to generate a compilation file containing attributedata describing currently available episodes in said series of episodes,and employing one of said one or more communication interfaces to: (1)receive a request via the Internet specifying said predetermined URLfrom a requesting client device for the updated version of saidcompilation file, (2) download said updated version of said compilationfile via the Internet to said requesting client device, and (3)thereafter receive and respond to a request from said requesting clientdevice for one or more media files identified by one or morecorresponding episode URLs included in the attribute data contained insaid updated version of said compilation file.
 2. Apparatus fordisseminating a series of episodes represented by media files via theInternet as said episodes become available as set forth in claim 1wherein at least some of said one or more media files representadvertisements and wherein said one or more processors employ one ormore of said communications interfaces to download one or more of saidmedia files representing advertisements to said requesting clientdevice.
 3. Apparatus for disseminating a series of episodes representedby media files via the Internet as said episodes become available as setforth in claim 1 wherein said compilation file further contains one ormore advertisement URLs specifying the storage location of media filesrepresenting advertisements that are reproduced by said requestingclient device.
 4. Apparatus for disseminating a series of episodesrepresented by media files via the Internet as said episodes becomeavailable as set forth in claim 1 wherein said attribute data describingeach given one of said currently available episodes further specifiesthe position of said given episode within said series of episodes. 5.Apparatus for disseminating a series of episodes represented by mediafiles via the Internet as said episodes become available as set forth inclaim 4 wherein at least some of said one or more media files representadvertisements and wherein said one or more processors employ one ormore of said communications interfaces to download one or more of saidmedia files representing advertisements to said requesting clientdevice.
 6. Apparatus for distributing a serialized sequence of episodesas said episodes become available, said apparatus comprising, incombination: one or more data storage servers for storing: a pluralityof media files each representing an episode in a serialized sequence ofepisodes and each containing a compressed audio recording, and adatabase containing attribute data describing each episode in saidserialized sequence of episodes, said attribute data including adisplayable text description of each of said episodes, an identificationof the serialized sequence of episodes to which each of said episodesbelongs, and a URL identifying each of said media files, one or morecommunications interfaces for receiving data requests from remote clientdevices and transmitting data files to said remote client devices inresponse to said requests, one or more processors coupled to said one ormore data storage servers and to said one or more communicationsinterfaces for: processing said attribute data in said database fromtime to time as new episodes in said serialized sequence becomeavailable to generate an updated compilation file that describes thecurrently available episodes in said serialized sequence, saidcompilation file including a displayable text description of each ofsaid currently available episodes and a URL identifying each media filerepresenting each of said currently available episodes, responding to acompilation file request specifying a predetermined compilation file URLby transmitting the updated compilation file that describes thecurrently available episodes in said serialized sequence to the remoteclient device requesting said updated compilation file, responding toeach media file request specifying the URL of a given one of said mediafiles by transmitting said given one of said media files to the remoteclient device requesting said given one of said media files. 7.Apparatus for distributing a serialized sequence of episodes as saidepisodes become available as set forth in claim 6 wherein said one ormore data storage servers further store media files representingadvertisements and wherein said one or more processors employ one ormore of said communications interfaces to download one or more of saidmedia files representing advertisements to one or more of said remoteclient devices.
 8. Apparatus for distributing a serialized sequence ofepisodes as said episodes become available as set forth in claim 6wherein said updated compilation file further includes one or moreadvertisement URLs identifying one or more media files representingadvertisements that can be retrieved and reproduced by said remoteclient device requesting said updated compilation file.
 9. Apparatus fordistributing a serialized sequence of episodes as said episodes becomeavailable as set forth in claim 6 wherein said plurality of media filesstored in said data storage server represent episodes in a plurality ofserialized sequences of episodes and wherein said attribute datacontained in said database includes, for each given one of saidcurrently available episodes, an identifier specifying the serializedsequence of episodes to which said given episode belongs.
 10. Apparatusfor distributing a serialized sequence of episodes as said episodesbecome available as set forth in claim 9 wherein said attribute datadescribing each given one of said currently available episodes furtherspecifies the position of said given episode within the serializedsequence of episodes to which said given episode belongs.
 11. Apparatusfor distributing a serialized sequence of episodes as said episodesbecome available as set forth in claim 10 wherein said one or more datastorage servers further store media files representing advertisementsand wherein said one or more processors employ one or more of saidcommunications interfaces to download one or more of said media filesrepresenting advertisements to one or more of said remote clientdevices.
 12. Apparatus for distributing a serialized sequence ofepisodes as said episodes become available as set forth in claim 10wherein said updated compilation file further includes one or moreadvertisement URLs identifying one or more media files representingadvertisements that can be retrieved and reproduced said remote clientdevice requesting said updated compilation file.